# XSS
## 1. XSS là gì?
XSS (*Cross-site scripting*) là một lỗ hổng bảo mật web cho phép kẻ tấn công xâm nhập vào các tương tác mà người dùng thực hiện với một ứng dụng dễ bị tấn công. Nếu người dùng có quyền truy cập đặc quyền vào ứng dụng thì kẻ tấn công có thể giành được toàn quyền kiểm soát tất cả chức năng và dữ liệu của ứng dụng.
## 2. Cách hoạt động của XSS
XSS cho phép kẻ tấn công chèn các đoạn mã độc thông qua các đoạn script để thực thi chúng ở phía client và ăn cắp dữ liệu nhận dạng của người dùng như cookies, session tokens và các thông tin khách.


Tấn công XSS nghĩa là gửi chèn lệnh và script độc hại, những mã đôc hại này thường được viết bằng các ngôn ngữ lập trình phía client như JavaScript, VBScript, Flash, HTML,… Tuy nhiên, cách tấn công này thường sử dụng JavaScript và HTML.

XSS hoạt động bằng cách điều khiển một trang web dễ bị tấn công để trả về JavaScript độc hại cho người dùng. Khi mã độc thực thi bên trong trình duyệt, kẻ tấn công hoàn toàn có thể xâm nhập vào tài khoản và sử dụng dữ liệu của người dùng.

Một số hình thức tấn công XSS có thể xảy ra:
- Xảy ra trên tập lệnh độc hại được thực hiện từ 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

Kẻ tấn công khai thác lỗ hổng XSS thường có thể:
- Mạo danh hoặc giả dạng người dùng nạn nhân.
- Thực hiện bất kỳ hành động nào mà người dùng có thể thực hiện.
- Đọc bất kỳ dữ liệu nào mà người dùng có thể truy cập.
- Nắm bắt thông tin đăng nhập của người dùng.
- Thực hiện deface ảo của trang web.
- Đưa chức năng trojan vào trang web.

Bất cứ cuộc tấn công XSS nào cũng đều phải trải qua 2 quy trình như sau:

- Đưa mã độc vào trình duyệt client mà nạn nhân muốn truy cập.
- Nạn nhân truy cập vào website có mã độc, khi đó, dữ liệu người dùng sẽ bị đánh cắp và bắt buộc họ phải đăng nhập tài khoản của mình bằng các thông tin khác. Thông thường, trong trường hợp hacker nhằm vào một nạn nhân cụ thể, URL chứa mã độc sẽ được gửi đến các nạn nhân thông qua kỹ thuật social engineering hay phishing.

## 3. Các loại tấn công
### 3.1. Reflected XSS
#### Reflected XSS là gì?

Reflected XSS xảy ra khi mã độc được phản ánh từ **yêu cầu HTTP** hiện tại và thực thi bởi trình duyệt của người dùng.

Với Reflected XSS, kẻ tấn công không gửi dữ liệu độc hại lên server nạn nhân, mà gửi trực tiếp link có chứa mã độc cho người dùng, khi người dùng click vào link này thì trang web sẽ được load chung với các đoạn script độc hại.

Reflected XSS thường dùng để ăn cắp cookie, chiếm session,… của nạn nhân hoặc cài keylogger, trojan … vào máy tính nạn nhân.

Giả sử một trang web có chức năng tìm kiếm cho người dùng trong tham số URL:

https://insecure-website.com/search?term=gift

Ứng dụng lặp lại cụm từ tìm kiếm được cung cấp trong phản hồi cho URL này:

<p>You searched for: gift</p>

Giả sử ứng dụng không thực hiện bất kỳ quá trình xử lý dữ liệu nào khác, kẻ tấn công có thể thực hiện một cuộc tấn công như thế này:

https://insecure-website.com/search?term=<script>/*+Bad+stuff+here...+*/</script>

URL này dẫn đến phản hồi sau:

<p>You searched for: <script>/* Bad stuff here... */</script></p>

Reflected XSS thường dùng để ăn cắp cookie, chiếm session,… của nạn nhân hoặc cài keylogger, trojan … vào máy tính nạn nhân. Một trong những cách được biết đến nhiều nhất là chiếm phiên làm việc (session) của người dùng, từ đó có thể truy cập được dữ liệu và chiếm được quyền của họ trên website:
#### Tác động của Reflected XSS
Khi có thể kiểm soát tập lệnh được thực thi trong trình duyệt của nạn nhân, kẻ tấn công có thể:
- Thực hiện bất kỳ hành động nào trong ứng dụng mà người có thể thực hiện.
- Xem bất kỳ thông tin nào mà người dùng có thể xem.
- Sửa đổi bất kỳ thông tin nào mà người dùng có thể sửa đổi.
- Bắt đầu tương tác với những người dùng ứng dụng khác, bao gồm cả các cuộc tấn công độc hại bắt nguồn từ người dùng ban đầu.

#### Cách tìm và kiểm tra Reflected XSS
Phần lớn Reflected XSS có thể được tìm thấy một cách nhanh chóng bằng cách sử dụng trình quét lỗ hổng web của Burp Suite.

Kiểm tra Reflected XSS bằng cách thủ công:
- Kiểm tra điểm vào: Kiểm tra riêng từng điểm nhập dữ liệu trong các yêu cầu HTTP của ứng dụng.
- Submit các giá trị chữ và số ngẫu nhiên
- Xác định reflection context
- Kiểm tra payload của ứng viên
- Kiểm tra payload thay thế
- Kiểm tra tấn công trên trên trình duyệt: Thông thường, cách tốt nhất là thực thi một số lệnh JavaScript đơn giản như `alert(document.domain)`, nó sẽ kích hoạt một cửa sổ bật lên hiển thị trong trình duyệt nếu cuộc tấn công thành công.
### 3.2. Stored XSS
#### Stored XSS là gì?

Stored XSS (còn gọi là second-order hoặc persistent XSS) là hình thức này nhắm đến nhiều nạn nhân cùng lúc, phát sinh khi ứng dụng nhận và lưu trữ dữ liệu từ một nguồn không đáng tin cậy và đưa dữ liệu đó vào các **phản hồi HTTP** theo cách không an toàn. Ví dụ như các form góp ý, các comment … trên các trang web.

Giả sử một trang web cho phép người dùng gửi nhận xét về các bài đăng trên blog và được hiển thị cho những người dùng khác. Người dùng gửi nhận xét bằng yêu cầu HTTP như sau:

POST /post/comment HTTP/1.1
Host: vulnerable-website.com
Content-Length: 100

postId=3&comment=Amazing+good+job.&name=Lucy&email=lucy%40normal-user.net

Sau khi nhận xét này được gửi, bất kỳ người dùng nào truy cập bài đăng trên blog sẽ nhận được những điều sau trong phản hồi của ứng dụng:

<p>Amazing good job.</p>

Giả sử ứng dụng không thực hiện bất kỳ quá trình xử lý dữ liệu nào khác, kẻ tấn công có thể gửi nhận xét độc hại như:

<script>/* Bad stuff here... */</script>

Theo yêu cầu của kẻ tấn công, nhận xét này sẽ được mã hóa URL dưới dạng:

comment=%3Cscript%3E%2F*%2BBad%2Bstuff%2Bhere...%2B*%2F%3C%2Fscript%3E

Giờ đây, bất kỳ người dùng nào truy cập bài đăng trên blog sẽ nhận được thông tin sau trong phản hồi của ứng dụng:

<p><script>/* Bad stuff here... */</script></p>

Tập lệnh do kẻ tấn công cung cấp sau đó sẽ thực thi trong trình duyệt của người dùng nạn nhân, trong bối cảnh session của họ với ứng dụng.
#### Tác động của Stored XSS
- Nếu kẻ tấn công có thể kiểm soát tập lệnh được thực thi trong trình duyệt của nạn nhân thì chúng thường có thể xâm phạm hoàn toàn người dùng đó. Kẻ tấn công có thể thực hiện bất kỳ hành động nào có thể áp dụng đối với tác động của các lỗ hổng reflected XSS.
- Lỗ hổng Stored XSS cho phép các cuộc tấn công độc lập trong chính ứng dụng. Kẻ tấn công không cần phải tìm cách bên ngoài để khiến người dùng thực hiện một yêu cầu cụ thể có chứa hoạt động khai thác của họ. Thay vào đó, kẻ tấn công xâm nhập vào chính ứng dụng và chỉ đợi người dùng gặp phải nó.
- Bản chất của việc khai thác Stored XSS là chỉ ảnh hưởng đến người dùng hiện đã đăng nhập vào ứng dụng.

#### Cách tìm và kiểm tra Stored XSS
Nhiều lỗ hổng stored XSS có thể được tìm thấy bằng trình quét lỗ hổng web của Burp Suite.

Việc kiểm tra các lỗ hổng Stored XSS theo cách thủ công có thể là một thách thức. Bạn cần kiểm tra tất cả các "điểm vào" có liên quan mà qua đó dữ liệu do kẻ tấn công kiểm soát có thể xâm nhập vào quá trình xử lý của ứng dụng và tất cả các "điểm thoát" mà tại đó dữ liệu đó có thể xuất hiện trong phản hồi của ứng dụng.

- Các điểm đầu vào trong quá trình xử lý của ứng dụng bao gồm:
- Các tham số hoặc dữ liệu khác trong chuỗi truy vấn URL và nội dung thư.
- Đường dẫn tệp URL.
- Các tiêu đề yêu cầu HTTP có thể không khai thác được liên quan đến Reflected XSS.
- Bất kỳ out-of-band routes nào mà kẻ tấn công có thể gửi dữ liệu vào ứng dụng.

- Các điểm thoát cho các cuộc tấn công Stored XSS là tất cả các phản hồi HTTP có thể được trả về cho bất kỳ loại người dùng ứng dụng nào trong mọi tình huống.

Gửi một giá trị cụ thể vào từng điểm và theo dõi phản hồi của ứng dụng để phát hiện các trường hợp giá trị được gửi xuất hiện. Có thể đặc biệt chú ý đến các chức năng ứng dụng có liên quan, chẳng hạn như *nhận xét* trên các bài đăng trên blog. Khi quan sát thấy giá trị đã gửi trong phản hồi, bạn cần xác định xem dữ liệu có thực sự được lưu trữ trên các yêu cầu khác nhau hay không, thay vì chỉ được phản ánh trong phản hồi

### So sánh Reflected XSS và Stored XSS
- Reflected XSS xảy ra khi một ứng dụng lấy một số đầu vào từ yêu cầu HTTP và nhúng đầu vào đó vào phản hồi.Thay vào đó, với Stored XSS ứng dụng sẽ lưu trữ dữ liệu đầu vào và nhúng nó vào phản hồi sau đó theo cách không an toàn.
- Để khai thác Reflected XSS, kẻ tấn công 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.
- Mục tiêu của hacker sẽ dễ dàng đạt được hơn nếu tại thời điểm tấn công nạn nhân vẫn trong phiên làm việc(session) của ứng dụng web. Với Reflected XSS, hacker có thể thuyết phục hay lừa nạn nhân đăng nhập rồi truy cập đến URL mà chúng cung cấp để 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 cứ khi nào người dùng truy cập các chức năng liên quan thì mã độc sẽ được thực thi, và nhiều khả năng là những chức nă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 gian này người dùng vẫn đang trong phiên làm việc.

=> Có thể thấy Stored XSS nguy hiểm hơn Reflected XSS rất nhiều, đối tượng bị ảnh hưởng có thế là tất cả 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ó nguy cơ bị chiếm quyền điều khiển web.
### 3.3. DOM Based XSS
#### DOM Based XSS là gì?
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, cụ thể là HTML.

Xảy ra khi lỗ hổng bảo mật tồn tại trong mã máy khách. DOM XSS có thể được sử dụng để ăn cắp cookie, session tokens, thông tin cá nhân, chiếm đoạt tài khoản, thay đổi nội dung trang web, chèn quảng cáo hoặc mã độc khác.

Để thực hiện một cuộc tấn công XSS dựa trên DOM, bạn cần đặt dữ liệu vào một nguồn để nó được truyền đến một nơi chìm và thực thi JavaScript tùy ý.

Nguồn phổ biến nhất cho DOM XSS là URL, thường được truy cập bằng `window.location`

Ví một ứng dụng sử dụng một số JavaScript để đọc giá trị từ trường input và ghi giá trị đó vào một phần tử trong HTML:

var search = document.getElementById('search').value;
var results = document.getElementById('results');
results.innerHTML = 'You searched for: ' + search;

Nếu kẻ tấn công có thể kiểm soát giá trị của trường đầu vào, chúng có thể dễ dàng tạo ra một giá trị độc hại khiến tập lệnh của chúng thực thi:

You searched for: <img src=1 onerror='/* Bad stuff here... */'>

#### Kiểm tra DOM Based XSS
Phần lớn các lỗ hổng DOM XSS có thể được tìm thấy nhanh chóng và đáng tin cậy bằng cách sử dụng trình quét lỗ hổng web của Burp Suite.

Để kiểm tra DOM Based XSS theo cách thủ công, bạn cần sử dụng trình duyệt có các công cụ dành cho nhà phát triển, chẳng hạn như Chrome.

- Kiểm tra phần chìm HTML: Để kiểm tra DOM XSS trong hệ thống chìm HTML, hãy đặt một chuỗi ký tự chữ và số ngẫu nhiên vào nguồn (chẳng hạn như `location.search`).Trong công cụ dành cho nhà phát triển của Chrome, bạn có thể sử dụng `Ctrl+F`(hoặc `Command+F` trên MacOS) để tìm kiếm chuỗi của mình trong DOM.
- Kiểm tra mức độ thực thi JavaScript chìm: bạn sẽ cần sử dụng trình gỡ lỗi JavaScript để xác định xem dữ liệu đầu vào của bạn có được gửi đến hệ thống xử lý hay không và bằng cách nào.
- Kiểm tra DOM XSS bằng DOM Invader: Bạn có thể tận dụng tiện ích mở rộng DOM Invader được tích hợp sẵn của Burp.

#### Những phần chìm có thể dẫn đến lỗ hổng DOM-XSS
Một số phần chìm chính có thể dẫn đến lỗ hổng DOM-XSS:

document.write()
document.writeln()
document.domain
element.innerHTML
element.outerHTML
element.insertAdjacentHTML
element.onevent

Các hàm jQuery sau đây cũng có thể dẫn đến lỗ hổng DOM-XSS:

add()
after()
append()
animate()
insertAfter()
insertBefore()
before()
html()
prepend()
replaceAll()
replaceWith()
wrap()
wrapInner()
wrapAll()
has()
constructor()
init()
index()
jQuery.parseHTML()
$.parseHTML()

### 3.4. Thực hiện xác định lỗi XSS
- Bước 1: Mở website cần kiểm tra
- Bước 2: Bắt đầu kiểm tra, định vị 1 ô tìm kiếm hoặc 1 login form và gửi thông tin đi (nhập thông tin và nhấn submit hay login hay ok gì đó), ví dụ nhập chữ "XSS" chẳng hạn hay chữ gì cũng được.
- Bước 3: Xác định khả năng website có bị lỗi XSS hay không bằng cách xem thông tin trả về:

· "Your search for 'XSS' did not find any items"
· "Your search for 'XSS' returned the following results"
· "User 'XSS' is not valid"
· "Invalid login 'XSS'"

- Bước 4: Hãy thử chèn những script này vào các ô input hay các biến trên thanh address để kiểm tra:

<script>alert('XSS')</script>
<i*g csstest=javascript:alert('XSS')>
&{alert('XSS')};

Nếu sau đó nhận được 1 popup có chữ "XSS" thì "alert" này 100% bị dính XSS. Tuy nhiên vẫn có trường hợp website đó bị dính XSS nhưng vẫn không xuất hiện cái popup thì phải VIEW SOURCES (xem mã nguồn). Khi view sources nếu có dòng <script>alert('XSS')</script> thì web dính lỗi XSS.
- Vượt qua cơ chế lọc XSS:
- Trong một số trường hợp, dữ liệu trả về xuất hiện trong phần Attribute Value: `<input type="text" name="state" value="INPUT_FROM_USER">`. Có thể sử dụng mã tấn công sau:`" onfocus="alert(document.cookie)`
- Trường hợp có sử dụng lọc, sử dụng cú pháp khác như:

"%3cscript%3ealert(document.cookie)%3c/script%3e">
"><script >alert(document.cookie)</script>

- Một số đoạn mã giúp vượt qua cơ chế lọc:

<IMG """><SCRIPT>alert("XSS")</SCRIPT>">
<IMG SRC=javascript:alert(String.fromCharCode(88,83,83))>
<IMG SRC=# onmouseover="alert('xxs')">
<IMG SRC= onmouseover="alert('xxs')">
<IMG SRC="jav ascript:alert('XSS');">
<IMG SRC="jav	ascript:alert('XSS');">
<IMG SRC="jav
ascript:alert('XSS');">
<IMG SRC="jav
ascript:alert('XSS');">
<<SCRIPT>alert("XSS");//<</SCRIPT>
<<SCRIPT>alert("XSS");//<</SCRIPT>
\";alert('XSS');//
<INPUT TYPE="IMAGE "SRC="javascript:alert('XSS');">
<IMG SRC='vbscript:msgbox("XSS")'>
<IFRAMESRC="javascript:alert('XSS');"></IFRAME>

## 4. Cách ngăn chặn XSS
### Data validation (xác định đầu vào)
Đảm bảo dữ liệu đầu vào được cung cấp với người dùng mạng là chính xác. Kiểm tra các giá trị đầu vào có hợp lệ hay không, có chứa các ký tự đặc biệt hay không, có phù hợp với định dạng mong muốn hay không.

Ví dụ:
- Nếu người dùng gửi một URL sẽ được trả về trong phản hồi, hãy xác thực rằng URL đó bắt đầu bằng một giao thức an toàn như HTTP và HTTPS. Nếu không, ai đó có thể khai thác trang web của bạn bằng giao thức có hại như javascript hoặc data.

### Filtering (lọc đầu vào người dùng)
Biện pháp này giúp tìm kiếm những keyword nguy hiểm có trong phần nhập của người dùng để kịp thời thay thế hoặc xóa bỏ chúng. Có thể sử dụng các hàm như `htmlentities()`, `htmlspecialchars()`, `strip_tags()` để mã hoá các ký tự đặc biệt thành các thực thể HTML.

### Output encoding (mã hoá đầu ra)
Biện pháp này giúp ngăn chặn trình duyệt thực thi các mã độc được chèn vào đầu ra của ứng dụng. Có thể sử dụng các hàm như `json_encode()`, `base64_encode()` để mã hoá các chuỗi đầu ra thành các định dạng khác nhau.

Ví dụ:
- Trong HTML, bạn nên chuyển đổi các giá trị không nằm trong danh sách cho phép thành các thực thể HTML:
- `<` chuyển đổi thành `&lt`;
- `>` chuyển đổi thành `&gt`;

- Trong JavaScript, các giá trị không phải chữ và số phải được thoát Unicode:
- `<` chuyển đổi thành `\u003c`
- `>` chuyển đổi thành `\u003e`
### Escape
Đây là biện pháp ngăn chặn XSS tương đối hiệu quả bằng cách thay đổi các ký tự bằng mã đặc biệt. Điều duy nhất bạn cần lưu ý trong trường hợp này là tìm kiếm thư viện Escape thích hợp. Ngoài ra, người dùng mạng cũng nên tự bảo vệ dữ liệu của mình bằng việc cẩn thận khi nhấp vào một link được chia sẻ nào đó. Đây là chiêu trò hay dùng của hacker khi tấn công XSS, đặc biệt là dạng Reflected XSS.

### Content Security Policy (chính sách bảo mật nội dung)
Biện pháp này giúp chỉ định những nguồn nội dung nào được phép chạy trên trang web. Có thể sử dụng các tiêu đề HTTP như `X-Content-Security-Policy`, `X-WebKit-CSP`, `Content-Security-Policy` để thiết lập các quy tắc cho các nguồn nội dung khác nhau như script, style, image, media,...

# Code

Thử nhập `<script>alert(1)</script>` vào ô `username` trong web đăng nhập bài trước:


Kết quả


Web dính lỗi XSS

# Write-up
https://github.com/aQ05/Write-up/blob/main/XSS.md