Theo Wikipedia nói rằng "Document Object Model (DOM) về cơ bản là một nền tảng và quy ước ngôn ngữ độc lập cho đại diện và tương tác với các đối tượng trong HTML, XHTML, và các tài liệu XML. Các nút của mỗi tài liệu được tổ chức trong một cấu trúc cây, được gọi là cây DOM. Các đối tượng trong cây DOM có thể được giải quyết và điều chỉnh bằng cách sử dụng các phương pháp trên đối tượng. Các giao diện công cộng của một DOM được quy định trong giao diện lập trình ứng dụng của nó (API). "
Để thể hiện một tài liệu như một trang HTML, hầu hết các trình duyệt web sử dụng một mô hình nội bộ tương tự như DOM. Các nút của mỗi tài liệu được tổ chức trong một cấu trúc cây, được gọi là cây DOM, với nút trên cùng có tên là "đối tượng tài liệu". Khi một trang HTML được kết xuất trong trình duyệt, trình duyệt sẽ tải HTML vào bộ nhớ địa phương và tự động phân tích nó để hiển thị trang trên màn hình. DOM cũng là cách truyền JavaScript trạng thái của trình duyệt trong các trang HTML.
DOM XSS ATTACK
DOM XSS là một cuộc tấn công XSS trong đó trọng tải của cuộc tấn công được thực hiện như là kết quả của việc sửa đổi DOM "môi trường" trong trình duyệt của nạn nhân được sử dụng bởi các kịch bản phía khách hàng ban đầu, do đó các mã phía máy khách chạy một cách "bất ngờ". Đó là, các trang riêng của mình (các phản ứng HTTP là) không thay đổi, nhưng mã phía khách hàng chứa trong trang web nạp vào khác nhau do những sửa đổi độc hại đã xảy ra trong môi trường DOM.
Dom XSS
Trong cuộc tấn công XSS dựa trên DOM, không có script độc hại chèn vào như một phần của trang; kịch bản duy nhất được thực hiện tự động trong quá trình tải trang là một phần hợp pháp của trang. Vấn đề là kịch bản hợp pháp này trực tiếp làm cho sử dụng của người sử dụng đầu vào để có thêm HTML vào trang. Bởi vì chuỗi độc hại được đưa vào sử dụng trang innerHTML, nó được phân tách như HTML, gây ra các script độc hại sẽ được thực thi.
Hãy hiểu DOM dựa vào một ví dụ:
Giả sử một nhà phát triển tạo ra một trang web và ông muốn là cung cấp nội dung trong nhiều ngôn ngữ tức là ông muốn người dùng của mình có thể chọn ngôn ngữ của sự lựa chọn của họ. Nhưng theo yêu cầu, trang web mush có một số ngôn ngữ mặc định quá. Chức năng này có thể được gọi bằng bên dưới URL:
http://www.abcdefg.com/page.html?default=English
DOM dựa XSS có thể đạt được nếu hacker có thể chèn code của mình trong thẻ mặc định và chuỗi tấn công sẽ giống như dưới đây:
SCRIPT >> </ script>
Khi nạn nhân click vào link này, trình duyệt sẽ gửi một yêu cầu:
/page.html?default=<script><<MALICIOUS SCRIPT >> </ script>
để www.abcdefg.com. Các máy chủ đáp ứng với các trang chứa trên mã Javascript. Các trình duyệt tạo ra một đối tượng DOM cho trang, trong đó đối tượng document.location chứa chuỗi:
SCRIPT >> </ script>
Các mã Javascript ban đầu trong các trang không mong đợi các thông số mặc định để chứa đánh dấu HTML, và như vậy nó chỉ đơn giản lặp lại nó vào trang (DOM) tại thời gian chạy. Các trình duyệt sau đó làm cho trang kết quả và thực hiện kịch bản của kẻ tấn công:
<< Mã SCRIPT Khai Thác >>
Lưu ý rằng các phản ứng HTTP được gửi từ máy chủ không chứa trọng tải của kẻ tấn công. tải trọng này biểu hiện ở các kịch bản phía máy khách trong thời gian chạy, khi một kịch bản không hoàn thiện truy cập các biến document.location DOM và giả định đó không phải là độc hại.
Lưu ý: Trong ví dụ trên, trong khi tải trọng không được nhúng bởi các máy chủ trong các phản ứng HTTP, nó vẫn đến máy chủ như là một phần của một yêu cầu HTTP, và do đó các cuộc tấn công có thể được phát hiện ở phía máy chủ.
Sửa lỗ hổng DOM Cross-site Scripting
Cách tốt nhất để sửa DOM dựa cross-site scripting là sử dụng phương pháp đầu ra bên phải. Ví dụ, nếu bạn muốn sử dụng đầu vào sử dụng để viết trong một thẻ <div> yếu tố không sử dụng innerHtml, thay vì sử dụng innerText / textContent. Điều này sẽ giải quyết vấn đề, và nó là đúng cách để khắc phục vulnerbilities XSS DOM
Nó luôn luôn là một ý tưởng tồi để sử dụng một đầu vào người sử dụng kiểm soát các nguồn nguy hiểm như eval. 99% thời gian đó là một dấu hiệu của thực hành lập trình tồi hay lười biếng, vì vậy chỉ cần không làm điều đó thay vì cố gắng để làm vệ sinh đầu vào.
Cuối cùng, để khắc phục các vấn đề trong mã ban đầu thay vì cố gắng để mã hóa đầu ra một cách chính xác đó là một rắc rối và có thể dễ dàng đi sai, chúng tôi chỉ đơn giản là sẽ sử dụng element.textContent để viết nó trong một nội dung như thế này:
<B> URL hiện tại: </ b> <span id = "contentholder"> </ span>
<Script>
document.getElementById ( "contentholder") textContent = document.baseURI.
</ Script>
Nó thực hiện điều tương tự nhưng lần này nó không phải là dễ bị tổn thương với các lỗ hổng cross-site scripting DOM
Chúc Các Bạn Thành Công Hẹn Gặp Ở Các Bài Sau!
Để thể hiện một tài liệu như một trang HTML, hầu hết các trình duyệt web sử dụng một mô hình nội bộ tương tự như DOM. Các nút của mỗi tài liệu được tổ chức trong một cấu trúc cây, được gọi là cây DOM, với nút trên cùng có tên là "đối tượng tài liệu". Khi một trang HTML được kết xuất trong trình duyệt, trình duyệt sẽ tải HTML vào bộ nhớ địa phương và tự động phân tích nó để hiển thị trang trên màn hình. DOM cũng là cách truyền JavaScript trạng thái của trình duyệt trong các trang HTML.
DOM XSS ATTACK
DOM XSS là một cuộc tấn công XSS trong đó trọng tải của cuộc tấn công được thực hiện như là kết quả của việc sửa đổi DOM "môi trường" trong trình duyệt của nạn nhân được sử dụng bởi các kịch bản phía khách hàng ban đầu, do đó các mã phía máy khách chạy một cách "bất ngờ". Đó là, các trang riêng của mình (các phản ứng HTTP là) không thay đổi, nhưng mã phía khách hàng chứa trong trang web nạp vào khác nhau do những sửa đổi độc hại đã xảy ra trong môi trường DOM.
Dom XSS
Trong cuộc tấn công XSS dựa trên DOM, không có script độc hại chèn vào như một phần của trang; kịch bản duy nhất được thực hiện tự động trong quá trình tải trang là một phần hợp pháp của trang. Vấn đề là kịch bản hợp pháp này trực tiếp làm cho sử dụng của người sử dụng đầu vào để có thêm HTML vào trang. Bởi vì chuỗi độc hại được đưa vào sử dụng trang innerHTML, nó được phân tách như HTML, gây ra các script độc hại sẽ được thực thi.
Hãy hiểu DOM dựa vào một ví dụ:
Giả sử một nhà phát triển tạo ra một trang web và ông muốn là cung cấp nội dung trong nhiều ngôn ngữ tức là ông muốn người dùng của mình có thể chọn ngôn ngữ của sự lựa chọn của họ. Nhưng theo yêu cầu, trang web mush có một số ngôn ngữ mặc định quá. Chức năng này có thể được gọi bằng bên dưới URL:
http://www.abcdefg.com/page.html?default=English
DOM dựa XSS có thể đạt được nếu hacker có thể chèn code của mình trong thẻ mặc định và chuỗi tấn công sẽ giống như dưới đây:
SCRIPT >> </ script>
Khi nạn nhân click vào link này, trình duyệt sẽ gửi một yêu cầu:
/page.html?default=<script><<MALICIOUS SCRIPT >> </ script>
để www.abcdefg.com. Các máy chủ đáp ứng với các trang chứa trên mã Javascript. Các trình duyệt tạo ra một đối tượng DOM cho trang, trong đó đối tượng document.location chứa chuỗi:
SCRIPT >> </ script>
Các mã Javascript ban đầu trong các trang không mong đợi các thông số mặc định để chứa đánh dấu HTML, và như vậy nó chỉ đơn giản lặp lại nó vào trang (DOM) tại thời gian chạy. Các trình duyệt sau đó làm cho trang kết quả và thực hiện kịch bản của kẻ tấn công:
<< Mã SCRIPT Khai Thác >>
Lưu ý rằng các phản ứng HTTP được gửi từ máy chủ không chứa trọng tải của kẻ tấn công. tải trọng này biểu hiện ở các kịch bản phía máy khách trong thời gian chạy, khi một kịch bản không hoàn thiện truy cập các biến document.location DOM và giả định đó không phải là độc hại.
Lưu ý: Trong ví dụ trên, trong khi tải trọng không được nhúng bởi các máy chủ trong các phản ứng HTTP, nó vẫn đến máy chủ như là một phần của một yêu cầu HTTP, và do đó các cuộc tấn công có thể được phát hiện ở phía máy chủ.
Sửa lỗ hổng DOM Cross-site Scripting
Cách tốt nhất để sửa DOM dựa cross-site scripting là sử dụng phương pháp đầu ra bên phải. Ví dụ, nếu bạn muốn sử dụng đầu vào sử dụng để viết trong một thẻ <div> yếu tố không sử dụng innerHtml, thay vì sử dụng innerText / textContent. Điều này sẽ giải quyết vấn đề, và nó là đúng cách để khắc phục vulnerbilities XSS DOM
Nó luôn luôn là một ý tưởng tồi để sử dụng một đầu vào người sử dụng kiểm soát các nguồn nguy hiểm như eval. 99% thời gian đó là một dấu hiệu của thực hành lập trình tồi hay lười biếng, vì vậy chỉ cần không làm điều đó thay vì cố gắng để làm vệ sinh đầu vào.
Cuối cùng, để khắc phục các vấn đề trong mã ban đầu thay vì cố gắng để mã hóa đầu ra một cách chính xác đó là một rắc rối và có thể dễ dàng đi sai, chúng tôi chỉ đơn giản là sẽ sử dụng element.textContent để viết nó trong một nội dung như thế này:
<B> URL hiện tại: </ b> <span id = "contentholder"> </ span>
<Script>
document.getElementById ( "contentholder") textContent = document.baseURI.
</ Script>
Nó thực hiện điều tương tự nhưng lần này nó không phải là dễ bị tổn thương với các lỗ hổng cross-site scripting DOM
Chúc Các Bạn Thành Công Hẹn Gặp Ở Các Bài Sau!
0 nhận xét:
Post a Comment