Ngăn chặn việc tiêm JavaScript trong ứng dụng web PHP

Question

Các biện pháp cần thiết để ngăn chặn hoặc ngăn chặn việc tiêm JavaScript xảy ra trong một ứng dụng Web PHP là gì để thông tin nhạy cảm không được đưa ra (thực hành tốt nhất trong PHP, HTML/XHTML và JavaScript)?

Answer 1

Bước đầu tiên tốt là áp dụng các phương pháp được liệt kê trong question Gert G linked. Này bao gồm các chi tiết sự đa dạng của các chức năng có thể được sử dụng trong các tình huống khác nhau để làm sạch đầu vào, bao gồm mysql_real_escape_string, htmlentities(), htmlspecialchars(), strip_tags() và addslashes()

Một cách tốt hơn, bất cứ khi nào có thể, là để tránh chèn đầu vào người sử dụng trực tiếp vào cơ sở dữ liệu của bạn . Sử dụng whitelist input validation: trong bất kỳ trường hợp nào bạn chỉ có một phạm vi tùy chọn giới hạn, hãy chọn từ các giá trị được mã hóa cứng để chèn, thay vì lấy đầu vào từ bất kỳ biểu mẫu nào của phía máy khách. Về cơ bản, điều này có nghĩa là chỉ có một số giá trị nhất định mà bạn chấp nhận, thay vì cố gắng loại bỏ/truy cập dữ liệu đầu vào độc ác/hình thành/độc hại.

Ví dụ: Nếu bạn có biểu mẫu có trình đơn thả xuống, không sử dụng đầu vào từ trình đơn thả xuống này để chèn. Hãy nhớ rằng một khách hàng độc hại có thể chỉnh sửa thông tin được gửi cùng với việc gửi biểu mẫu, ngay cả khi bạn cho rằng họ chỉ có các tùy chọn giới hạn. Thay vào đó, có thả xuống tham chiếu đến một chỉ mục trong một mảng trong mã phía máy chủ của bạn. Sau đó sử dụng mảng đó để chọn nội dung cần chèn. Bằng cách này, ngay cả khi kẻ tấn công cố gắng gửi cho bạn mã độc hại, nó không bao giờ thực sự truy cập cơ sở dữ liệu của bạn.

Rõ ràng, điều này không hoạt động đối với các ứng dụng dạng tự do như diễn đàn hoặc blog. Đối với những người đó, bạn phải quay trở lại các kỹ thuật "bước đầu tiên". Tuy nhiên, có một loạt các tùy chọn có thể được cải thiện thông qua xác thực đầu vào danh sách trắng.

Bạn cũng có thể sử dụng parameterized queries (còn gọi là câu lệnh đã chuẩn bị có biến liên kết) cho tương tác sql của bạn bất cứ khi nào có thể. Điều này sẽ cho máy chủ cơ sở dữ liệu của bạn biết rằng tất cả đầu vào chỉ đơn giản là một giá trị, do đó nó giảm thiểu rất nhiều vấn đề tiềm năng từ các cuộc tấn công tiêm. Trong nhiều tình huống, điều này thậm chí có thể bao gồm các ứng dụng dạng tự do.

Answer 2

Nếu bất cứ điều gì không đi qua của bạn cần phải được formated như html sau đó sử dụng:

strip_tags() <- Eliminates any suspicious html 

và sau đó chạy phần sau đây để làm sạch trước khi lưu vào db

mysql_real_escape_string() 

Nếu ajax của bạn được tiết kiệm người dùng nhập html qua một hộp văn bản hoặc wysiwyg sau đó xem xét sử dụng HTMLPurifier để loại bỏ javascript nhưng cho phép các thẻ html.

Answer 3

Xử lý bất kỳ giá trị nào bạn xuất ra thành html với htmlspecialchars() theo mặc định.

Chỉ có lý do không sử dụng htmlspecialchars() là khi bạn cần xuất ra chuỗi html chứa chính html. Trong trường hợp đó, bạn phải chắc chắn rằng chuỗi này là từ nguồn hoàn toàn an toàn. Nếu bạn không có sự tự tin như vậy thì bạn phải vượt qua nó thông qua bộ lọc html danh sách trắng chỉ cho phép tập hợp các thẻ, thuộc tính và giá trị thuộc tính được giới hạn cẩn thận. Bạn nên đặc biệt cẩn thận về các giá trị thuộc tính. Bạn không bao giờ nên cho phép mọi thứ chuyển thành giá trị thuộc tính đặc biệt cho các thuộc tính như src, hef, style.

Bạn nên biết tất cả các địa điểm trong webapp nơi bạn xuất bất kỳ thứ gì vào html mà không sử dụng htmspeciachars(), hãy chắc chắn rằng bạn thực sự cần những địa điểm đó và lưu ý rằng mặc dù tất cả sự tự tin của bạn là những nơi dễ bị tổn thương.

Nếu bạn nghĩ rằng điều này là quá nhiều cảnh báo: "Tại sao tôi cần htmlspecialchar() biến này mà tôi biết nó chỉ chứa số nguyên và mất tất cả các chu kỳ CPU quý giá?" Hãy nhớ điều này: Bạn không biết, bạn chỉ nghĩ rằng bạn biết, chu trình CPU là điều rẻ nhất trên thế giới và gần như tất cả chúng sẽ bị lãng phí bằng cách đợi cơ sở dữ liệu hoặc hệ thống tập tin hoặc thậm chí truy cập bộ nhớ.

Cũng không bao giờ sử dụng bộ lọc html danh sách đen. Youtube đã phạm sai lầm đó và một người nào đó đột nhiên phát hiện ra rằng chỉ <script> bị xóa đầu tiên và nếu bạn nhập câu hỏi thứ hai vào nhận xét, bạn có thể đưa bất kỳ Javascript nào vào trình duyệt của khách truy cập.

Tương tự như vậy để tránh SQL Injection xử lý với mysql_real_escape_string() tất cả các giá trị mà bạn dán vào truy vấn SQL, hoặc sử dụng tốt hơn các câu lệnh PDO Prepared.

Answer 4

Tôi không đồng ý đầy đủ với các câu trả lời khác được cung cấp vì vậy tôi sẽ đăng các đề xuất của tôi.

Đề xuất đọc XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

Html Injection: Bất cứ khi nào hiển thị bất kỳ người sử dụng gửi nội dung, nó nên được một cách thích hợp dọn dẹp với htmlspecialchars hoặc htmlentities khi xác định ENT_QUOTES nếu được sử dụng bên trong dấu nháy đơn. Tôi sẽ khuyên bạn không bao giờ đóng gói trong dấu nháy đơn và luôn đóng gói các thuộc tính của bạn trong dấu ngoặc kép (không bỏ qua chúng). Này áp dụng cho những thứ như:

<input value="<?php echo htmlspecialchars($var); ?>" /> 
<textarea><?php echo htmlspecialchars($var); ?></textarea> 
<p><?php echo htmlspecialchars($var); ?></p> 
<img width="<?php echo htmlspecialchars($var); ?>" /> 

Javascript Injection: Đó là thực tế tốt nhất (nhưng không phải luôn luôn thực tế) để không bao giờ vang nội dung người dùng vào các sự kiện và javascript. Tuy nhiên, nếu bạn làm có một số điều có thể được thực hiện để giảm nguy cơ. Chỉ vượt qua số nguyên id. Nếu bạn yêu cầu một cái gì đó như một loại specifier, sau đó sử dụng một danh sách trắng và/hoặc kiểm tra có điều kiện trước thời hạn trước khi xuất ra. Có thể buộc nội dung của người dùng chỉ có chữ và số khi thích hợp; preg_replace("/[^A-Za-z0-9]/", '', $string); nhưng phải rất cẩn thận những gì bạn cho phép ở đây. Chỉ bao gồm nội dung khi nó được đóng gói trong dấu ngoặc kép và lưu ý rằng htmlspecialchars/htmlentities không bảo vệ bạn ở đây. Nó sẽ được giải thích tại thời gian chạy ngay cả khi nó đã được dịch sang các thực thể html. này áp dụng cho những thứ như:

<a href="www.stackoverlow.com/?id=<?php echo (int)$id; ?>">Click</a> 
href, src, style, onClick, etc. 

Đừng vang bất kỳ nội dung người dùng sang các lĩnh vực khác như cơ thể của thẻ script vv trừ khi nó đã bị buộc phải một int hoặc một số bộ ký tự rất rất hạn chế khác (nếu Bạn biết những gì bạn đang làm).

Chèn SQL: Sử dụng Prepared statements, ràng buộc nội dung người dùng với họ và không bao giờ chèn trực tiếp nội dung người dùng vào truy vấn. Tôi khuyên bạn nên tạo một lớp cho các câu lệnh đã chuẩn bị với các hàm trợ giúp cho các kiểu câu lệnh cơ bản khác nhau của bạn (và trong khi về chủ đề này, chức năng hóa tất cả các câu lệnh cơ sở dữ liệu của bạn). Nếu bạn chọn không sử dụng câu lệnh đã chuẩn bị thì hãy sử dụng mysql_real_escape_string() hoặc tương tự (không phải là dấu gạch chéo()). Xác thực nội dung khi có thể trước khi lưu trữ vào cơ sở dữ liệu như bắt buộc/kiểm tra kiểu dữ liệu nguyên, kiểm tra có điều kiện trên các loại, v.v. Sử dụng các kiểu cột và độ dài cột cơ sở dữ liệu thích hợp. Hãy nhớ rằng mục tiêu chính ở đây là để ngăn chặn tiêm sql nhưng bạn có thể tùy chọn làm bảo vệ tiêm html/javascript ở đây là tốt.

Tài nguyên khác Tôi đã thực hiện một số nghiên cứu trực tuyến với hy vọng tìm được giải pháp đơn giản đã có sẵn công khai. Tôi tìm thấy OWASP ESAPI nhưng nó xuất hiện khá ngày. Các liên kết đến phiên bản php bị hỏng ở nhiều nơi. Tôi tin rằng tôi đã tìm thấy nó ở đây; ESAPI PHP nhưng một lần nữa nó là khá ngày và không đơn giản như tôi đã hy vọng. Tuy nhiên, bạn có thể thấy nó hữu ích.

Tất cả trong tất cả, đừng bao giờ giả sử bạn được bảo vệ như sử dụng htmlentities trong thuộc tính onClick. Bạn phải sử dụng đúng công cụ ở đúng vị trí và tránh làm những việc sai vị trí.