2010-08-09 29 views
7

Làm thế nào để tránh các cuộc tấn công tập lệnh chéo trang web?Làm thế nào để tránh "Tấn công trên nhiều trang web"

Cross-site script attacks (hoặc cross-site scripting) là nếu bạn ví dụ có một lưu bút trên trang chủ của bạn và một khách hàng viết một số mã javascript mà FX chuyển hướng bạn đến một trang web khác hoặc gửi cookie của bạn trong một email cho một người dùng độc hại hoặc có thể có nhiều thứ khác có thể chứng minh là có hại cho bạn và những người truy cập trang của bạn.

Tôi chắc chắn rằng nó có thể được thực hiện fx. trong PHP bởi xác thực biểu mẫu nhưng tôi không đủ kinh nghiệm để fx. cấm javascript hoặc những thứ khác có thể gây hại cho bạn.

Tôi hy vọng bạn hiểu câu hỏi của tôi và bạn có thể giúp tôi.

+0

Khung mục tiêu? PHP? – Arthur

+0

Có các tùy chọn cho bất kỳ ngôn ngữ/khuôn khổ nào/v.v. Bạn sẽ nhận được câu trả lời cụ thể hơn - như htmlencode - nếu bạn cung cấp thêm thông tin về thiết lập của mình. (Cây rơm). – Tobiasopdenbrouw

+0

Bạn nói đúng, Tobiasopdenbrouw, nhưng nó thực sự giống như một câu hỏi chung mà người khác cũng có thể đạt được từ :) – Latze

Trả lời

12

tôi chắc chắn rằng nó có thể được thực hiện fx. bằng PHP bằng cách xác thực các biểu mẫu

Không thực sự. Giai đoạn đầu vào hoàn toàn là nơi sai để giải quyết các vấn đề XSS.

Nếu người dùng nhập, giả sử <script>alert(document.cookie)</script> vào đầu vào, không có gì sai với chính nó. Tôi đã làm điều đó trong tin nhắn này, và nếu StackOverflow không cho phép chúng tôi gặp khó khăn lớn khi nói về JavaScript trên trang web! Trong hầu hết các trường hợp, bạn muốn cho phép bất kỳ đầu vào nào (*), để người dùng có thể sử dụng ký tự < theo nghĩa đen nghĩa là dấu nhỏ hơn.

Điều là, khi bạn viết một số văn bản vào một trang HTML, bạn phải thoát nó một cách chính xác cho ngữ cảnh mà nó đi vào. Đối với PHP, có nghĩa là sử dụng htmlspecialchars() ở giai đoạn đầu ra:

<p> Hello, <?php echo htmlspecialchars($name); ?>! </p> 

[PHP gợi ý: bạn có thể xác định cho mình một chức năng với một tên ngắn hơn để làm echo htmlspecialchars, vì đây là khá nhiều cách gõ để làm mỗi thời gian bạn muốn đặt biến vào một số HTML.]

Điều này là cần thiết bất kể văn bản đến từ đâu, cho dù đó là từ biểu mẫu do người dùng gửi hay không. Trong khi dữ liệu do người dùng gửi là nơi nguy hiểm nhất để quên mã hóa HTML của bạn, thì điểm thực sự là bạn đang lấy một chuỗi ở một định dạng (văn bản thuần túy) và chèn nó vào một ngữ cảnh ở định dạng khác (HTML).Bất cứ lúc nào bạn ném văn bản vào một ngữ cảnh khác, bạn sẽ cần một lược đồ mã hóa/thoát ra phù hợp với ngữ cảnh đó.

Ví dụ: nếu bạn chèn văn bản vào chuỗi chữ JavaScript, bạn sẽ phải thoát khỏi ký tự trích dẫn, dấu gạch chéo ngược và dòng mới. Nếu bạn chèn văn bản vào một thành phần truy vấn trong một URL, bạn sẽ cần phải chuyển đổi hầu hết các phần không phải chữ số thành các chuỗi %xx. Mọi bối cảnh đều có các quy tắc riêng; bạn phải biết đó là chức năng phù hợp cho từng ngữ cảnh trong ngôn ngữ/khung được lựa chọn của bạn. Bạn không thể giải quyết những vấn đề này bằng cách gửi biểu mẫu mangling ở giai đoạn đầu vào - mặc dù nhiều lập trình viên PHP ngây thơ đã thử, đó là lý do tại sao rất nhiều ứng dụng làm hỏng đầu vào của bạn trong các trường hợp góc và vẫn không an toàn.

(*: tốt, hầu như bất kỳ. Có một lý lẽ hợp lý để lọc ra các ký tự điều khiển ASCII khỏi văn bản đã gửi. Rất khó cho phép chúng hoạt động tốt. bạn sẽ muốn làm, như đảm bảo một trường e-mail trông giống như một địa chỉ email hoặc các con số đó thực sự là số. Nhưng đây không phải là thứ có thể được áp dụng cho tất cả các đầu vào để giúp bạn thoát khỏi rắc rối.)

9

Tấn công tập lệnh cross-site (XSS) xảy ra khi máy chủ chấp nhận đầu vào từ máy khách và sau đó viết một cách mù quáng đầu vào đó trở lại trang. Hầu hết các bảo vệ từ các cuộc tấn công liên quan đến việc thoát khỏi đầu ra, do đó, Javascript biến thành HTML đơn giản.

Một điều cần nhớ là không chỉ dữ liệu đến trực tiếp từ ứng dụng khách có thể chứa một cuộc tấn công. A Lưu trữ XSS tấn công liên quan đến việc viết JavaScript độc hại vào cơ sở dữ liệu, nội dung của họ sau đó được truy vấn bởi ứng dụng web. Nếu cơ sở dữ liệu có thể được ghi riêng biệt với máy khách, ứng dụng có thể không chắc chắn rằng dữ liệu đã được thoát đúng cách. Vì lý do này, ứng dụng web sẽ xử lý tất cả dữ liệu mà nó ghi vào máy khách như thể nó có thể chứa một cuộc tấn công.

Xem liên kết này cho một nguồn tài nguyên kỹ lưỡng về cách tự bảo vệ mình: http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

+0

Điểm tuyệt vời - Tôi thấy cách nói quá nhiều thường là "đầu vào chà", trong thực tế điều đó không phải lúc nào cũng có thể ngay cả khôn ngoan, và nó không hoàn toàn giải quyết vấn đề anyway. Các giải pháp cần phải xảy ra ở thời gian đầu ra. Ngoài ra, điều quan trọng cần lưu ý là HTML không phải là ngữ cảnh dễ bị tổn thương duy nhất - SQL Injection thực sự chỉ là một biến thể trên cùng một chủ đề. – Pointy

+0

Xác thực đầu vào, thoát khỏi đầu ra –

Các vấn đề liên quan