XSS – Cross Site Scripting – [part 3 – XSS Auditor]

What is XSS Auditor?

XSS ngày càng trở nên phổ biến, hậu quả mà nó mang lại cũng khôn lường. XSS xuất hiện khắp nơi trên các ứng dụng web. Việc xây dựng một trang web không có lỗi XSS không hề dễ dàng. Đội ngũ bảo mật của các trình duyệt web biết điều đó, nên họ đã giúp cho cuộc sống của dev dễ thể hơn bằng cách phát triển các bộ lọc giúp tự động phát hiện và ngăn chặn XSS.

Internet Explore giới thiệu tính năng XSS Filter, Google Chrome không kém cạnh khi phát triển XSS Auditor, cả 2 đều được bật mặc định trên browser. Ông lớn Firefox với lợi thế mã nguồn mở thì có addon NoScript với chức năng tương tự.

XSS Filter và XSS Auditor có cơ chế hoạt động khá tương đồng, và đều có thể được bật qua HTTP Header X-XSS-Protection. Trong bài này tôi sẽ nói về XSS Auditor, bộ lọc do Google phát triển.

 

---

How does XSS Auditor works?

Trong bài báo mà đội ngũ phát triển của Google Chrome công bố, họ cho rằng XSS Auditor tốt hơn bộ lọc của các Browser khác vì 2 lý do: nhanh hơn, bảo mật hơn.

http://www.collinjackson.com/research/xssauditor.pdf?source=post_page

Họ cũng giải thích rất rõ cách thức hoạt động của XSS Auditor. Về cơ bản, browser sẽ scan tất cả các tham số trong request, nhận ra đoạn script nguy hiểm và so sánh nó với response từ server. Nếu đoạn script này xuất hiện trong response, browser sẽ nhận biết đó là một cuộc tấn công XSS và sẽ hoặc là lọc bỏ, hoặc là block luôn.

Cách thức hoạt động của XSS Auditor như vậy chỉ ngăn chặn được Reflected XSS vì mã độc được reflect trực tiếp vào response, nó hoàn toàn không được thiết kế để ngăn chặn Stored XSS và DOM based XSS.

XSS Auditor được bật mặc định, hoặc bạn có thể tùy chỉnh cấu hình nó thông qua HTTP Header X-XSS-Protection.

X-XSS-Protection có 3 chế độ:

1. X-XSS-Protection: 0: tắt bộ lọc
2. X-XSS-Protection: 1: bật bộ lọc ở chế độ filter, browser chỉ lọc mã độc, không block response từ server.
3. X-XSS-Protection: 1; mode=block: bật bộc lọc ở chế độ block, nếu phát hiện mã độc browser sẽ block luôn response và trả về trang thông báo lỗi.

 

Proof-of-concept:

• X-XSS-Protection: 0

 

• X-XSS-Protection: 1

 

• X-XSS-Protection: 1; mode=block

XSS Auditor quả thực đã giúp ngăn chặn rất nhiều cuộc tấn công Reflected XSS từ trong trứng nước. Thế nhưng, liệu các nhà phát triển ứng dụng web có thể tin tưởng hoàn toàn vào bộ lọc này? Đọc xong bài này bạn sẽ có câu trả lời cho mình.

 

---

Multi Reflection XSS

Multi Reflection XSS xảy ra khi input không được validate của user xuất hiện nhiều hơn 1 vị trí trong response, hay nói cách khác trang web bị lỗi XSS ở nhiều vị trí. Lúc này, XSS Auditor sẽ dễ dàng bị bypass. Tại sao? Xem ví dụ sẽ rõ:

Multi Reflection – multi input

Ứng dụng có 2 chỗ bị XSS: tham số name và age. Xem response từ server sẽ hiểu ngay cách mà payload hoạt động. XSS Auditor chỉ scan mỗi tham số một cách riêng lẻ nên khi ta chia payload ra thành 2 phần, mỗi phần nhỏ đều không thể là mã độc, nên XSS Auditor sẽ không block nó. Thế nhưng khi kết hợp 2 phần lại thì boom, we have bypassed XSS Auditor!

 

Multi Reflection – single input

Ở đây, cùng một input được render vào 2 vị trí khác nhau trong trang web. Payload hơi khác một chút:

Tham khảo thêm tại:

https://turkmenog.lu/blog/2017/11/06/yet-another-chrome-xss-auditor-bypass/

 

---

Abusing the block mode – XS Search

Ban đầu khi giới thiệu XSS Auditor, Google Chrome thiết lập chế độ mặc định là filter mode. Sau đó đã có một vài báo cáo về các lỗ hổng trong chế độ filter mode, nên Google quyết định chuyển chế độ mặc định sang block mode. Thế nhưng block mode cũng không an toàn, nó dễ bị tấn công bởi các kỹ thuật Side Channel Attack như XS-Search, hay XS-Leak.

XS-Search xảy ra khi hacker lợi dụng sự khác nhau trong các response khi thực hiện truy vấn liên quan đến user dể leak thông tin về user.

Ta hãy cũng xem ví dụ được lấy từ FacebookCTF 2019, bài Secret Note Keeper.

https://github.com/fbsamples/fbctf-2019-challenges/tree/master/web/secret_note_keeper

Tôi đã mô phỏng lại challenge trên localhost:

Sau khi đăng nhập, ứng dụng cho ta 3 chức năng chính: tạo 1 Notes mới và lưu lại, search 1 Notes mà ta đã lưu (search theo nội dung) và report link lỗi cho admin.

Tôi sẽ bỏ qua giai đoạn Recon mà đi thẳng vào Bug & Exploit. Vì ta có thể report link đến Admin, đây có thể là 1 bài dạng Client-Site Attack, và cụ thể là XSS. Bot Admin sử dụng Headless Chrome, được thiết lập XSS Auditor mặc định.

Để ý rằng khi search được 1 Note, ứng dụng sẽ tạo 1 <iframe> mới để chứa nội dung Note. Vì server không set Header X-Frame-Options: DENY nên ta có thể dùng iframe để chứa trang web lỗi. Vậy ta sẽ tạo 1 server, dùng iframe để include target_site, dùng chức năng iframe.contentWindow.frames.length để đếm số iframe được tạo trong target_site, nếu có iframe mới được tạo chứng tỏ chuỗi truy vấn đúng. Ta dùng nó để brute fore chuỗi truy vấn, từ đó có được flag.

Đoạn code sau để bypass tính năng proof-of-work và report link đến admin.

Sau khi bot admin truy cập link chứa script exploit (ở đây là http://localhost/ex.html), browser của admin sẽ thực hiện script brute force trong link, và gửi kết quả về cho ta.

Nội dung file ex.html

Ở đây thay vì dùng bot, tôi sẽ demo bằng cách mở Google Chrome và vào link trên (tôi đóng vai trò là admin đã đăng nhập).

Khi truy cập link được attacker gửi:

flag được gửi về server của hacker:

Write-up chi tiết (của 1 team khác) có thể đọc tại:

https://sectt.github.io/writeups/FBCTF19/secret_note_keeper/README

Tham khảo về XS-Search

https://github.com/xsleaks/xsleaks

 

---

Abusing the filter mode – Disable Arbitrary Script

Block mode tỏ ra không an toàn trước các cuộc tấn công Side Channel Attack như XS-Search. Sau nhiều báo cáo về lỗ hổng này

https://portswigger.net/daily-swig/new-xs-leak-techniques-reveal-fresh-ways-to-expose-user-information

Google đã quyết định thiết lập chế độ mặc định về filter mode.

https://portswigger.net/daily-swig/google-chromes-xss-auditor-goes-back-to-filter-mode

Thế nhưng các hacker thế giới thì sáng tạo không ngừng, họ lại tiếp tục tìm ra cách khai thác lỗ hổng của filter mode.

Ta biết rằng, khi set XSS Auditor ở mode filter. Nếu browser phát hiện đoạn script trong tham số request giống với nội dung response nó sẽ bất hoạt đoạn code đó. Vậy nếu hacker copy một đoạn script trong response vào tham số request thì sao, XSS Auditor nhận biết đó là XSS attack và sẽ bất hoạt script trong response. Như vậy hacker có thể bất hoạt đoạn script bất kỳ trong response. Xem ví dụ:

Đoạn script của response đã bị browser bất hoạt vì cho rằng nó được reflect từ một cuộc tấn công XSS.

Xem thêm writup về bài DOM Validator trong AngstrongCTF 2019, tác giả đã dùng kĩ thuật trên để bất hoạt đoạn script quan trọng làm logic ứng dụng bị phá vỡ.

https://github.com/justcatthefish/ctf/tree/master/2019-04-25-Angstrom2019/web#%C3%A5ngstromctf-2019—-quick-write-ups-by-terjanq-web

 

Một payload khác có thể bypass filter mode vẫn hoạt động đến hôm nay:

<svg><use%20href%3D”data%3Aimage%2Fsvg%2Bxml%2C<svg%20id%3D%27x%27%20xmlns%3D%27http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%27%20xmlns%3Axlink%3D%27http%3A%2F%2Fwww.w3.org%2F1999%2Fxlink%27%20width%3D%27100%27%20height%3D%27100%27><a%20xlink%3Ahref%3D%27javascript%3Aalert(1)%27><rect%20x%3D%270%27%20y%3D%270%27%20width%3D%27100%27%20height%3D%27100%27%20%2F><%2Fa><%2Fsvg>%23x”%20%2F>

 

 

---

Side Channel Info 🙂

Sau khi đổi qua đổi lại giữa 2 mode của XSS Auditor, Google nhận ra một điều là chẳng có cái nào là an toàn cả, chẳng những vậy còn khiến phát sinh thêm các lỗi mới mà developper không mong muốn. Thế nên, cách đây không lâu (thật ra là mới chỉ 2 tuần trước bài blog này), ngày 16/7/2019, Google đã quyết định … khai tử XSS Auditor trong version Chrome kế tiếp :v

https://portswigger.net/daily-swig/google-deprecates-xthú vịss-auditor-for-chrome

Sự thật là trình duyệt Microsoft Edge cũng đã disable XSS Filter của họ trước đó 1 năm 🙂

Quả là cái kết thú vị cho XSS filter!

Phần sau tôi sẽ nói về Content Security Policy, một tính năng hứa hẹn có thể thay thế XSS Auditor