🔏Cross-site scripting(XSS)
Client Side Vul
Last updated
Client Side Vul
Last updated
XSS là một lỗ hổng web cho phép kẻ tấn công xâm phạm tới tương tác giữa người dùng và ứng dụng bị tấn công.
Các lỗ hổng XSS trên nhiều trang web thường cho phép kẻ tấn công 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 và truy cập bất kỳ dữ liệu nào của người dùng. Nếu người dùng nạn nhân có quyền truy cập đặc quyền trong ứng dụng, thì kẻ tấn công có thể có toàn quyền kiểm soát tất cả các chức năng và dữ liệu của ứng dụng.
XSS hoạt động bằng cách thao túng web bị tấn công bằng cách trả về JS độc hại tới người dùng. Khi dòng code độc hại được thực thi bên trong trình duyệt của nạn nhân thì kẻ tấn công có thể thao túng được tương tác giữa người dùng và ứng dụng.
Reflected XSS – nơi mà script độc hại đến từ HTTP request hiện tại
Stored XSS – nơi mà script độc hại đến từ database của website
DOM-based XSS – nơi mà lỗ hổng bảo mật tồn tại trongclient-side code chứ không phải server-side code
Reflected XSS là một dạng đơn giản nhất của XSS. Nó phát sinh khi một ứng ụng nhận dữ liệu trong một HTTP request và bao gồm dữ liệu phản hồi ngay lập tức theo một cách không an toàn
https://insecure-website.com/search?term=gift
Chèn script vào ___ https://insecure-website.com/search?term=<script>/*+Bad+stuff+here...+*/</script>
Thật ra để biết nó bị dính lỗi XSS hay không chỉ cần alert(1) xem có hiện ra hay không…..
Nếu kẻ tấn công có thể kiểm soát mộ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 đó. Trong số những thứ khác, 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 dùng 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, dường như bắt nguồn từ người dùng nạn nhân ban đầu.
Nếu ai chưa biết cookie là gì hãy đọc ở đây
Đánh cắp cookies là một cách truyền thống để khai thác XSS. Hầu hết các ứng dụng web đều sử dụng cookies cho việc xử lý session. Bạn có thể khai thác XSS để gửi cookies của nạn nhân tới tên miền của bạn( dùng Requestbin) và sau đó nhập cookies vào trình duyệt của bạn và giả dạng nạn nhân.
Trên thực tế, cách tiếp cận này có một số hạn chế đáng kể:
Nạn nhân có thể không đăng nhập.
Nhiều ứng dụng ẩn cookie của họ khỏi JavaScript bằng HttpOnly flag.
Các Session có thể bị khóa đối với các yếu tố bổ sung như địa chỉ IP của người dùng.
Session có thể hết thời gian trước khi bạn có thể chiếm quyền điều khiển.
Ngày nay, nhiều người dùng có trình quản lý mật khẩu tự động điền mật khẩu của họ. Bạn có thể tận dụng điều này bằng cách tạo một đầu vào mật khẩu, đọc mật khẩu tự động điền và gửi mật khẩu đó đến miền của riêng bạn. Kỹ thuật này tránh được hầu hết các vấn đề liên quan đến ăn cắp cookie và thậm chí có thể truy cập vào mọi tài khoản khác mà nạn nhân đã sử dụng lại cùng một mật khẩu.
Nhược điểm chính của kỹ thuật này là nó chỉ hoạt động trên những người dùng có trình quản lý mật khẩu thực hiện tự động điền mật khẩu.
Fetch API
Bất cứ điều gì người dùng hợp pháp có thể làm trên một trang web, bạn cũng có thể làm với XSS. Tùy thuộc vào trang web bạn đang nhắm mục tiêu, bạn có thể khiến nạn nhân gửi tin nhắn, chấp nhận yêu cầu kết bạn, cam kết một cửa sau vào kho lưu trữ mã nguồn hoặc chuyển một số Bitcoin.
Một số trang web cho phép người dùng đã đăng nhập thay đổi địa chỉ email của họ mà không cần nhập lại mật khẩu. Nếu bạn đã tìm thấy lỗ hổng XSS, bạn có thể kích hoạt chức năng này để thay đổi địa chỉ email của nạn nhân thành địa chỉ email mà bạn kiểm soát, sau đó kích hoạt đặt lại mật khẩu để có quyền truy cập vào tài khoản.
Loại khai thác này thường được gọi là giả mạo yêu cầu trên nhiều trang web (CSRF), điều này hơi khó hiểu vì CSRF cũng có thể xảy ra như một lỗ hổng độc lập. Khi CSRF xảy ra như một lỗ hổng độc lập, nó có thể được vá bằng các chiến lược như mã thông báo chống CSRF. Tuy nhiên, các chiến lược này không cung cấp bất kỳ biện pháp bảo vệ nào nếu cũng có lỗ hổng XSS.
Khi kiểm tra cho Reflected hay Stored XSS thì nhiệm vụ chính là xác định bối cảnh XSS
Vị trí phản hồi nơi mà dữ liệu có thể tấn công và điều khiển
Bất kỳ xác thực đầu vào hoặc xử lý khác đang được ứng dụng thực hiện trên dữ liệu đó.
Khi tình huống XSS là văn bản giữa HTML tags thì bạn cần thêm một thẻ HTML mới để JS được thực thi.
Một số cách hữu ích để thực thi JavaScript là:
Khi tấn công Reflected XSS vào HTML context với các thẻ và thuộc tính bị blocked
Khi chúng ta thử <img src=1 onerror=alert(1)> nếu mà lỗi thì chúng ta dùng Burp Suite để check thẻ và thuộc tính nào k bị block
Đây là XSS cheat sheet để paste vào list
Nếu bạn không tìm thấy bất kỳ thẻ HTML hợp lệ nào, bạn có thể thử tạo một thẻ tùy chỉnh và thực thi mã JS với thuộc tính onfocus attribute. Trong XSS request, , bạn cần kết thúc URL bằng # để làm cho trang tập trung vào đối tượng đó và thực thi mã:
SVG: Các bạn có thể xem tại đây
Tạo ra một thẻ attributeNamw là href và gán giá trị nó là javascript:alert(1)
Khi XSS context là một giá trị thuộc tính của thẻ HTML, đôi khi bạn có thể chấm dứt giá trị thuộc tính, đóng thẻ và giới thiệu một giá trị mới.
Trong trường hợp này, dấu ngoặc nhọn bị chặn hoặc được mã hóa, vì vậy thông tin đầu vào của bạn không thể thoát ra khỏi thẻ mà nó xuất hiện. Với điều kiện bạn có thể kết thúc giá trị thuộc tính, thông thường bạn có thể giới thiệu một thuộc tính mới tạo ra ngữ cảnh có thể tập lệnh, chẳng hạn như trình xử lý sự kiện.
Trọng tải ở trên tạo sự kiện onfocus sẽ thực thi JavaScript khi phần tử nhận được tiêu điểm và cũng thêm thuộc tính tự động lấy nét để cố gắng kích hoạt sự kiện onfocus tự động mà không cần bất kỳ tương tác nào của người dùng. Cuối cùng, nó thêm x = “để sửa chữa một cách duyên dáng đánh dấu sau.
Đôi khi XSS context nằm trong một loại thuộc tính thẻ HTML mà chính nó có thể tạo ra một ngữ cảnh có thể tập lệnh. Tại đây, bạn có thể thực thi JavaScript mà không cần kết thúc giá trị thuộc tính.
Ví dụ: nếu XSS context nằm trong thuộc tính href của thẻ liên kết, bạn có thể sử dụng giao thức giả javascript để thực thi tập lệnh.
Bạn có thể gặp các trang web mã hóa dấu ngoặc nhọn nhưng vẫn cho phép bạn đưa các thuộc tính vào. Đôi khi, những lần tiêm này có thể xảy ra ngay cả trong các thẻ thường không tự động kích hoạt các sự kiện, chẳng hạn như thẻ chuẩn. Bạn có thể khai thác hành vi này bằng cách sử dụng các khóa truy cập và tương tác của người dùng trên Chrome.
Các phím truy cập cho phép bạn cung cấp các phím tắt tham chiếu đến một phần tử cụ thể. Thuộc tính accesskey cho phép bạn xác định một chữ cái, khi được nhấn kết hợp với các phím khác, sẽ gây ra các sự kiện để kích hoạt. Trong phòng thí nghiệm tiếp theo, bạn có thể thử nghiệm với các accesskey và khai thác thẻ chuẩn.
Reflected XSS in canonical link tag: Sử dung accesskey để khi người dùng sử dụng phím tắt thì dữ liệu vô tình được gửi.
Kết thúc Script hiện có:
Trong trường hợp đơn giản nhất, có thể chỉ cần đóng thẻ script đang bao quanh JavaScript hiện có và giới thiệu một số thẻ HTML mới sẽ kích hoạt thực thi JavaScript.
thì bạn có thể sử dụng tải trọng sau để thoát khỏi JavaScript hiện có và thực thi:
Trong trường hợp XSS context nằm bên trong một chuỗi được trích dẫn, thường có thể thoát ra khỏi chuỗi và thực thi JavaScript trực tiếp. Điều cần thiết là phải sửa chữa tập lệnh theo ngữ cảnh XSS, vì bất kỳ lỗi cú pháp nào ở đó sẽ ngăn toàn bộ tập lệnh thực thi.
Một số ứng dụng cố gắng ngăn đầu vào thoát ra khỏi chuỗi JavaScript bằng cách thoát bất kỳ ký tự trích dẫn đơn lẻ nào có dấu gạch chéo ngược. Dấu gạch chéo ngược trước một ký tự cho bộ phân tích cú pháp JavaScript biết rằng ký tự đó phải được hiểu theo nghĩa đen, và không phải là một ký tự đặc biệt như dấu chấm dứt chuỗi. Trong tình huống này, các ứng dụng thường mắc lỗi không thể thoát khỏi chính ký tự dấu gạch chéo ngược. Điều này có nghĩa là kẻ tấn công có thể sử dụng ký tự dấu gạch chéo ngược của riêng họ để vô hiệu hóa dấu gạch chéo ngược được ứng dụng thêm vào.
Các bạn có thể đọc ở đây
';alert(document.domain)//
Sau đó nó chuyển đổi thành như này:
\';alert(document.domain)//
Lúc đó bạn đã sử dụng thêm dấu \ để khi nhập vào thì \\ thì nó sẽ thành \:
\';alert(document.domain)//
Cuối cùng nó sẽ là:
\\';alert(document.domain)//
///////////////////////////////////////////////////////////////////////////
Khi XSS context là một JavaScript hiện có trong thuộc tính thẻ được trích dẫn, chẳng hạn như trình xử lý sự kiện, có thể sử dụng mã hóa HTML để làm việc xung quanh một số bộ lọc đầu vào.
Khi trình duyệt đã phân tích cú pháp các thẻ và thuộc tính HTML trong một phản hồi, trình duyệt sẽ thực hiện giải mã HTML các giá trị thuộc tính thẻ trước khi chúng được xử lý thêm. Nếu ứng dụng phía máy chủ chặn hoặc mã hóa một số ký tự cần thiết để khai thác XSS thành công, bạn thường có thể bỏ qua xác thực đầu vào bằng cách mã hóa HTML các ký tự đó.
<a href="#" onclick="... var input='controllable data here'; ...">
Khi đó ứng dụng sẽ chặn hoặc mã hóa các ký tự đơn và bạn có thể sử dụng này load này để thoát ra khỏi chuỗi JS và thực thi pl:
'-alert(document.domain)-'
Chuỗi ' là một thực thể HTML đại diện cho một dấu nháy đơn hoặc một dấu ngoặc kép. Vì HTML của trình duyệt giải mã giá trị của thuộc tính onclick trước khi JavaScript được diễn giải, các thực thể được giải mã dưới dạng dấu ngoặc kép, trở thành dấu phân cách chuỗi và do đó cuộc tấn công thành công.
Các ký tự mẫu JavaScript là các ký tự chuỗi cho phép các biểu thức JavaScript được nhúng. Các biểu thức nhúng được đánh giá và thường được nối với văn bản xung quanh. Các ký tự mẫu được đóng gói trong dấu gạch ngược thay vì dấu ngoặc kép bình thường và các biểu thức nhúng được xác định bằng cú pháp $ {…}.
document.getElementById('message').innerText = `Welcome, ${user.displayName}.`;
Bạn chỉ cần sử dụng cú pháp $ {…} để nhúng biểu thức JavaScript sẽ được thực thi khi xử lý ký tự.
thì bạn có thể sử dụng trọng tải sau để thực thi JavaScript
${alert(document.domain)}
///////Cập nhật sau///////
Test mọi đầu vào
Gửi random các giá trị số và chữ
Xem xét reflection context
Test các payload có thể
Test cuộc tấn trong trình duyệt
Stored XSS xảy ra khi ứng dụng nhận dữ liệu từ một nguồi không tin cậy và bao gồm những dữ liệu với cùng HTTP responses một cách không an toàn.
Giả sử một trang web cho phép người dùng gửi comments lên bài đăng của blog, nó sẽ được hiển thị với những người dùng khác. Người dùng gửi comment đang sử dụng một HTTP request như này:
Sau khi nhận xét này được gửi đi, bất kỳ người dùng nào truy cập vào 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>This post was extremely helpful.</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 một bình luận ác ý như thế này
<script>/* Bad stuff here... */</script>
Trong yêu cầu của kẻ tấn công, nhận xét này sẽ được mã hóa URL thành:
comment=%3Cscript%3E%2F*%2BBad%2Bstuff%2Bhere...%2B*%2F%3C%2Fscript%3E
Hậu quả và cách thức khai thác nó gần như giống reflected XSS
Các lỗ hổng XSS DOM thường phát sinh khi JavaScript lấy dữ liệu từ một nguồn có thể kiểm soát được của kẻ tấn công, chẳng hạn như URL và chuyển nó đến một phần mềm hỗ trợ thực thi mã động, chẳng hạn như eval () hoặc innerHTML. Điều này cho phép những kẻ tấn công thực thi JavaScript độc hại, thường cho phép chúng chiếm đoạt tài khoản của người dùng khác.
Khai thác DOM XSS với các nguồn và phần chìm khác nhau
Về nguyên tắc, một trang web dễ bị tấn công bởi tập lệnh trang web chéo dựa trên DOM nếu có một đường dẫn thực thi mà qua đó dữ liệu có thể truyền từ nguồn đến trang chìm. Trong thực tế, các source và sinks khác nhau có các thuộc tính và cách xử lý8 khác nhau có thể ảnh hưởng đến khả năng khai thác và xác định những kỹ thuật nào là cần thiết. Ngoài ra, các tập lệnh của trang web có thể thực hiện xác thực hoặc xử lý dữ liệu khác phải được cung cấp khi cố gắng khai thác lỗ hổng bảo mật. Có một loạt các điểm sinks có liên quan đến các lỗ hổng dựa trên DOM.
Phần document.write sink hoạt động với các phần tử script, vì vậy bạn có thể sử dụng một payload đơn giản, chẳng hạn như phần bên dưới:
document.write('... <script>alert(document.domain)</script> ...');
Tuy nhiên, lưu ý rằng trong một số trường hợp, nội dung được viết vào document.write bao gồm một số context xung quanh mà bạn cần tính đến khi khai thác. Vậy bạn có thể cần phải đóng một số phần tử hiện có trước khi sử dụng tải trọng JavaScript của mình.
Mình thường gọi nó là break out JS String hoặc HTML Tags
Khi chúng ta khai thác những trang có chưa sản phẩm hãy dùng dev tool nó có trích xuất tham số từ nguồn không và nó sử dụng document.write để tạo mới mà chú ý tham số nó tạo mới là cái nào thì từ đó chúng ta có thể chèn script vào từ đó và gửi nó đi
interHTML sink không chấp nhận các phần tử tập lệnh trên bất kỳ trình duyệt hiện đại nào, cũng như các sự kiện svg onload sẽ kích hoạt. Điều này có nghĩa là bạn sẽ cần sử dụng các phần tử thay thế như img hoặc iframe. Các trình xử lý sự kiện như onload và onerror có thể được sử dụng cùng với các phần tử này.
Sources and sinks trong phụ thuộc của bên thứ ba
Các ứng dụng web hiện đại thường được xây dựng bằng cách sử dụng một số thư viện và khuôn khổ của bên thứ ba, thường cung cấp các chức năng và khả năng bổ sung cho các nhà phát triển. Điều quan trọng cần nhớ là một số trong số này cũng là nguồn tiềm năng và là điểm chìm cho DOM XSS.
Nếu một thư viện JavaScript như jQuery đang được sử dụng, hãy chú ý đến các phần chìm có thể thay đổi các phần tử DOM trên trang.
Ví dụ, attr() hàm của jQuery có thể thay đổi các thuộc tính của các phần tử DOM. Nếu dữ liệu được đọc từ một nguồn do người dùng kiểm soát như URL, sau đó được chuyển đến attr() hàm, thì có thể thao túng giá trị được gửi để gây ra XSS.
Ví dụ: ở đây chúng tôi có một số JavaScript thay đổi href thuộc tính của phần tử bằng cách sử dụng dữ liệu từ URL:
$(function() { $('#backLink').attr("href",(new URLSearchParams(window.location.search)).get('returnUrl')); });
Bạn có thể khai thác điều này bằng cách sửa đổi URL để location.search nguồn chứa URL JavaScript độc hại. Sau khi JavaScript của trang áp dụng URL độc hại này vào liên kết quay lại href, việc nhấp vào liên kết quay lại sẽ thực thi nó:
?returnUrl=javascript:alert(document.domain)
Một điểm khác tiềm năng cần chú ý là $() chức năng bộ chọn của jQuery, có thể được sử dụng để đưa các đối tượng độc hại vào DOM.
jQuery từng cực kỳ phổ biến và lỗ hổng DOM XSS cổ điển là do các trang web sử dụng bộ chọn này kết hợp với location.hash nguồn cho hoạt ảnh hoặc tự động cuộn đến một phần tử cụ thể trên trang gây ra. Hành vi này thường được thực hiện bằng cách sử dụng hashchange trình xử lý sự kiện dễ bị tấn công, tương tự như sau:
Vì hashngười dùng có thể kiểm soát được, kẻ tấn công có thể sử dụng điều này để đưa một vectơ XSS vào $() bộ chọn chìm. Các phiên bản jQuery gần đây hơn đã vá lỗ hổng cụ thể này bằng cách ngăn bạn đưa HTML vào bộ chọn khi đầu vào bắt đầu bằng ký tự băm ( #). Tuy nhiên, bạn vẫn có thể tìm thấy mã dễ bị tấn công trong tự nhiên.Để thực sự khai thác lỗ hổng cổ điển này, bạn sẽ cần tìm cách kích hoạt hashchange sự kiện mà không cần sự tương tác của người dùng. Một trong những cách đơn giản nhất để làm điều này là cung cấp khai thác của bạn thông qua iframe:
<iframe src="https://vulnerable-website.com#" onload="this.src+='<img src=1 onerror=alert(1)>'">
Trong ví dụ này, src attribute thuộc tính trỏ đến trang dễ bị tấn công với giá trị băm trống. Khi iframe được tải, một vectơ XSS được thêm vào hàm băm, khiến hashchange sự kiện kích hoạt.
Note:
Các phiên bản cập nhật của jQuery đã vá lỗ hổng này để ngăn chặn hành động mờ ám là inject HTML vô selector với input bắt đầu bằng hash character (#);
Các phiên bản mới của jQuery vẫn có thể ăn hành thông qua các lỗ hổng với selector $ khi đầu vào không yêu cầu # prefix.
AngularJs là một framework JavaScript được sử dụng để tạo ra các ứng dụng giàu tính năng trên Internet (RIA – Rich Internet Application), bao gồm cả ứng dụng Web App và ứng dụng Mobile App. Nó cho phép lập trình viên tạo ra những mẫu client-side dựa trên kiến trúc Model-View-Control (MVC). Angular JS sử dụng các biểu thức tích hợp nhằm tạo ra HTML template.
Nó quét nội dung của các nút HTML có chứa ng-app thuộc tính (còn được gọi là chỉ thị AngularJS). Khi một chỉ thị được thêm vào mã HTML, bạn có thể thực thi các biểu thức JavaScript trong dấu ngoặc nhọn kép. Kỹ thuật này hữu ích khi các dấu ngoặc nhọn đang được mã hóa. {{}}
{{constructor.constructor('alert(0)')()}}
or {{$on.constructor('alert(1)')()}}
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 thay đổi bề mặt ảo của trang web.
Chèn chức năng trojan vào trang web.
Trong một số trường hợp, việc ngăn chặn tập lệnh chéo trang là việc nhỏ nhưng có thể khó hơn nhiều tùy thuộc vào độ phức tạp của ứng dụng và cách ứng dụng xử lý dữ liệu do người dùng kiểm soát.
Nói chung, việc ngăn chặn hiệu quả các lỗ hổng XSS có thể liên quan đến sự kết hợp của các biện pháp sau:
Lọc đầu vào khi đến. Tại thời điểm nhận được đầu vào của người dùng, hãy lọc càng chặt chẽ càng tốt dựa trên những gì được mong đợi hoặc đầu vào hợp lệ.
Mã hóa dữ liệu trên đầu ra. Tại điểm mà dữ liệu do người dùng kiểm soát được xuất ra trong phản hồi HTTP, hãy mã hóa đầu ra để ngăn nó được hiểu là nội dung đang hoạt động. Tùy thuộc vào ngữ cảnh đầu ra, điều này có thể yêu cầu áp dụng kết hợp mã hóa HTML, URL, JavaScript và CSS.
Sử dụng tiêu đề phản hồi thích hợp. Để ngăn XSS trong phản hồi HTTP không có ý định chứa bất kỳ HTML hoặc JavaScript nào, bạn có thể sử dụng tiêu đề Content-Type và X-Content-Type-Options để đảm bảo rằng các trình duyệt diễn giải phản hồi theo cách bạn dự định.
Chính sách Bảo mật Nội dung. Là tuyến phòng thủ cuối cùng, bạn có thể sử dụng Chính sách bảo mật nội dung (CSP) để giảm mức độ nghiêm trọng của bất kỳ lỗ hổng XSS nào vẫn xảy ra.
Сhi tiết hơn thì đọc ở đây ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[link]
Nói chung trong thực tế thì để kiếm ra lỗi XSS không hề đơn giản mà chúng ta cần phải suy nghĩa nhiều giờ/ngày/… để có thể tấn công được.
Cảm ơn các bạn đã đọc bài ! Bài Research XSS sẽ tạm dừng tại đây và có thể trở lại một bài viết về XSS nâng cao hơn…
