<span class="text_page_counter">Trang 1</span><div class="page_container" data-page="1">

KHOA CÔNG NGHỆ THÔNG TIN

BÁO CÁO ĐỀ TÀI

Năm học:

2020-2021 Đề tài :

Website chia sẻ thông tin dành cho IT

Giảng viên hướng dẫn

Lê Thị Minh Châu

Sinh viên thực hiện :

Nguyễn Thị Minh Hoàng 18110285 Nguyễn Huỳnh Minh Tiến 18110377

PHIẾU NHẬN XÉT CỦA GIẢNG VIÊN HƯỚNG DẪN TPHCM, tháng 6 năm 2021.

</div><span class="text_page_counter">Trang 2</span><div class="page_container" data-page="2">

Họ và tên Sinh viên 2 : Trần Ngọc Minh Thiện MSSV 2: 18110371 Họ và tên Sinh viên 3 : Nguyễn Huỳnh Minh Tiến MSSV 3: 18110377

Ngành: Công Nghệ Thông Tin.

Tên đề tài: Website chia sẻ thông tin dành cho IT. Họ và tên Giảng viên hướng dẫn: Lê Thị Minh Châu.

Giáo viên hướng dẫn (Ký & ghi rõ họ tên)

</div><span class="text_page_counter">Trang 3</span><div class="page_container" data-page="3">

Nhóm 18 chúng em xin cảm ơn Cơ Lê Thị Minh Châu, đã tận tình chỉ dạy, hướng dẫn, sửa sai, chia sẻ về kiến thức và kinh nghiệm đến với nhóm em cũng như cả lớp học. Bài báo cáo này là kết quả của mơn học mà có sự giảng dạy của Cơ làm nền tảng để nhóm em có thể hồn thành báo cáo một cách hoàn chỉnh và đưa ra sản phẩm tốt nhất có thể. Nhóm chúng em xin chân thành cảm ơn Cơ.

TPHCM, ngày 20 tháng 6 năm 2021 Nhóm 18

</div><span class="text_page_counter">Trang 4</span><div class="page_container" data-page="4">

PHÂN CÔNG CÔNG VIỆC...1

PHẦN 1. GIỚI THIỆU ĐỀ TÀI...2

1. Sơ lược về đề tài...2

1.1. Giới thiệu...2

1.2. Các chức năng chính...2

2. Lược đồ usecase... 3

3. Lược đồ quan hệ (ERD)...4

4. Hướng dẫn cài đặt và chạy...5

4.1. Sơ lược về project...5

4.2 Hướng dẫn cài đặt... 6

4.3 Tiến hành chạy...11

PHẦN 2. BẢO MẬT WEBSITE...13

1. Các lỗi OWASP ZAP quét...13

1.1 Cookie No HttpOnly Flag...13

</div><span class="text_page_counter">Trang 5</span><div class="page_container" data-page="5">

4.3 NoSQL Injection wordlists...39

4.4 Lý giải ngun do khơng có lỗ hổng MongoDB NoSQL Injection trong ứng dụng ... 47

</div><span class="text_page_counter">Trang 6</span><div class="page_container" data-page="6">

5.1 Khái niệm...52

5.2 Các biện pháp chống tràn bộ nhớ đệm...52

5.3 Tấn công project với Buffer overflow...53

6. Lỗi quét được bằng Synk.io...54

TÀI LIỆU THAM KHẢO...59

</div><span class="text_page_counter">Trang 7</span><div class="page_container" data-page="7">

PHÂN CÔNG CƠNG VIỆC

18110285 Nguyễn Thị Minh Hồng ^{- Khắc phục các lỗi của Cross-Site Scripting – XSS} - Khắc phục lỗi Buffer overflow

18110371 Trần Ngọc Minh Thiện

Sửa các lỗi của ZAP:

- The Cross-Domain JavaScript Source File Inclusion

- Incomplete or No Cache-control Header Set 18110377 Nguyễn Huỳnh Minh Tiến

- Tìm kiếm lỗ hổng bảo mật NoSQL Injection và hướng khắc phục

- Quét tìm lỗ hổng với Synk.io

18110402 Lê Thị Ngọc Yến

Sửa các lỗi của ZAP: - Cookie No HttpOnly Flag - X-Frame-Options Header Not Set - Cookie without SameSite Attribute Hạn chế bị Tấn công Brute Force

P a g e 1 | 65

</div><span class="text_page_counter">Trang 8</span><div class="page_container" data-page="8">

PHẦN 1. GIỚI THIỆU ĐỀ TÀI

1. Sơ lược về đề tài 1.1. Giới thiệu

Website 4XFIT là một Website lưu trữ những bài viết thảo luận, những câu hỏi hay những câu trả lời được cộng đồng sinh viên giải đáp nhằm tạo ra một cộng động để chia sẻ kinh nghiệm lập trình, nhất là cho sinh viên chuyên ngành công nghệ thông tin hoặc cho các sinh viên có đam mê và tìm hiểu cơng nghệ thơng tin. Người dùng có thể đăng những bài viết của mình sau khi đã tạo tài khoản và đăng nhập thành công, những người dùng này sẽ chịu sự kiểm soát của admin hệ thống. Những người dùng khác có thể xem và bình luận dưới những bài viết sau khi đã đăng nhập.

Gồm có 3 đối tượng chính sử dụng website là:

Admin : người có tồn quyền quản lí website, cấp quyền cho người dùng hệ thống (Editor) và quản lý người dùng thường.

Guest : người dùng chỉ ghé thăm website mà khơng đăng kí hoặc đăng nhập, người dùng này khơng có quyền tương tác với website, chỉ có quyền xem.

User thường: người dùng đã đăng kí và đăng nhập vào website, có quyền tương tác với website.

User hệ thống (Mod/Editor): người quản lý bài viết và chủ đề, phê duyệt bài viết. 1.2. Các chức năng chính

Chỉnh sửa bài viết Duyệt người dùng

Vote bài viết Chia sẻ bài viết Tìm kiếm bài viết

</div><span class="text_page_counter">Trang 9</span><div class="page_container" data-page="9">

2. Lược đồ usecase

P a g e 3 | 65

</div><span class="text_page_counter">Trang 10</span><div class="page_container" data-page="10">

3. Lược đồ quan hệ (ERD)

</div><span class="text_page_counter">Trang 11</span><div class="page_container" data-page="11">

4. Hướng dẫn cài đặt và chạy 4.1. Sơ lược về project

- Link project: - Ngơn ngữ lập trình: Java

- Framework: Java Servlet

- Cơ sở dữ liệu: MongoDB Atlas (Cloud DBaaS for MongoDB) - Server: Apache Tomcat server (version 9.0)

- Version control: GitHub - IDE: Eclipse

- Webapp được deploy lên Heroku 4.2 Hướng dẫn cài đặt

Bước 1: Import project vào workspace Eclipse chọn File > Import > Existing Maven Projects > Browse để tìm đường và chọn folder muốn import > Finish

</div><span class="text_page_counter">Trang 12</span><div class="page_container" data-page="12">

Có thể có lỗi xuất hiện như hình bên dưới

Cài đặt thêm thư viện vào thư mục Libraries

</div><span class="text_page_counter">Trang 13</span><div class="page_container" data-page="13">

Các thư viện - có trong link drive:

usp=sharing

P a g e 7 | 65

</div><span class="text_page_counter">Trang 14</span><div class="page_container" data-page="14">

Tiếp đến, kiểm tra xem đã có JRE chưa, nếu chưa có thì thêm vào.

Nhấn chuột phải vào project chọn Build Path > Configure Build Path > Add Library > JRE System Library > Next > Workspace default JRE > Finish > Apply and Close

</div><span class="text_page_counter">Trang 15</span><div class="page_container" data-page="15">

Thêm Tomcat server vào Eclipse, chọn Window > Preferences > Server > Runtime Environments > Add > Apache > Apache Tomcat v9.0 (có thể chọn Apache Tomcat v8.0) > Next > Browse để tìm đường dẫn và chọn folder Tomcat > Finish > Apply and Close

P a g e 9 | 65

</div><span class="text_page_counter">Trang 16</span><div class="page_container" data-page="16">

4.3 Tiến hành chạy

Nhấn chuột phải vào project chọn Run As > Run on Server > Tomcat v9.0 Server > Next > Chọn project muốn chạy (chọnx4Fit) > Finish

Server đã được cài đặt

</div><span class="text_page_counter">Trang 17</span><div class="page_container" data-page="17">

Mở trình duyệt và nhập: http://localhost:8080/x4fit/ Sẽ vào trang home của trang web

Chọn button login vào trang login Tài khoản admin:

</div><span class="text_page_counter">Trang 18</span><div class="page_container" data-page="18">

PHẦN 2. BẢO MẬT WEBSITE

1. Các lỗi OWASP ZAP quét

1.1 Cookie No HttpOnly Flag 1.1.1 Httponly flag là gì ?

Để tránh trường hợp một số kẻ tấn công chèn mã độc khi click vào một đường dẫn và lấy cắp thông tin cookie xác thực đăng nhập mà không được bảo vệ bởi HttpOnly nên dẫn tới việc mất thông tin.

Khi Httponly không được set hoặc set bằng false thì chỉ cần thực hiện bằng một đoạn lên javascript đơn giản là đã có thơng tin cookie.

document.cookie = "authKey cookie c a XXX";ủ

Trang web của nhóm khi chưa set cờ true cho Httponly Chèn một đoạn code:

</textarea><script>alert(document.cookie)</script><textarea>

</div><span class="text_page_counter">Trang 19</span><div class="page_container" data-page="19">

Tồn bộ những thuộc tính của cookie không được set cờ Httponly đều hiện lên. Mục đích của thuộc tính Httponly là bảo vệ cookie tránh việc truy cập trái phép từ brower. Chỉ lưu và gửi kèm cookie phản hồi từ client đến server. Nếu cookie được set cờ Httponly nó khơng thể bị truy cập bởi client thơng qua Javascript. Điều đó có nghĩa hacker khơng thể đọc giá trị hoặc thậm chí khơng biết cookie có tồn tại hay khơng.

1.1.2 Xử lý

Code xử lý thêm các dòng hightlight vào để bật cờ true cho HttpOnly

<small>if ( account_id != null) {</small>

<small>//L uư cookie</small>

<small>String selector = RandomStringUtils.randomAlphanumeric(12);String rawValidator = RandomStringUtils.randomAlphanumeric(64);String hashedValidator = DigestUtils.sha256Hex(rawValidator);</small>

<small>Authentication auth = new Authentication(account_id selector, , </small>

<small>Cookie cookieSelector = new Cookie("selector", selector);</small>

<small>Cookie cookieValidator = new Cookie("validator", </small>

P a g e 13 | 65

</div><span class="text_page_counter">Trang 20</span><div class="page_container" data-page="20">

<small>Cookie cookieIsLogged = new Cookie("is_logged" "true", );</small>

Và thêm vào file web.xml

</div><span class="text_page_counter">Trang 21</span><div class="page_container" data-page="21">

1.2 Cookie without SameSite Attribute 1.2.1 SameSite Cookie

SameSite Cookie là thuộc tính thêm vào trong cookie để yêu cầu chủ sở hữu trang web ghi rõ ràng nhãn cookie của Web khác, nhờ đó chỉ có thể chia sẻ Cookie với các trang web này. Như vậy một website lừa đảo khơng thể giả mạo người dùng vì khơng thể lấy được Cookie.

Lợi ích của SameSite giúp cho việc chống tấn công CSFR dễ dàng và hiệu quả hơn. Người làm hệ thống sẽ giảm chi phí do khơng cần bổ sung tính năng tạo và tương tác thơng qua token ở client và server. Hiệu năng của hệ thống được nâng cao khi không phải sinh và đối chiếu token.

SameSite là một thuộc tính của Set-Cookie trong Http response header. Có 3 giá trị: - SameSite = Strict

Giá trị của Strict phòng ngừa các web giả mạo mạnh mẽ. Trình duyệt sẽ ngăn cản dữ liệu cookie chuyển giữa các tên miền chéo khác trong mọi trường hợp. Cookie sẽ không được gửi cùng với các request được bắt đầu với các trang web thứ 3. Đặt cookie là Strict có thể ảnh hưởng tiêu cực đến trải nghiệm duyệt web. Ví dụ: nếu bạn nhấp vào 1 liên kết dẫn đến trang profile của Facebook, và Facebook.com đặt cookie của nó là SameSite=Strict thì bạn khơng thể tiếp tục redirect trên Facebook trừ khi bạn đăng nhập lại vào Facebook. Lý do là vì Cookie của Facebook không được gửi kèm với request này.

- SameSite = Lax

Trình duyệt cho phép chia sẻ cookie giữa các trang web có cùng miền, cookie sẽ được gửi cùng với GET request được tạo bởi bên thứ 3.

- SameSite = None 1.2.2 Xử lý

Phần này tạo thêm 1 class <small>HttpService</small>

<small>FastDateFormat.getInstance("EEE, dd MMM yyyy HH:mm:ss zzz", </small>

P a g e 15 | 65

</div><span class="text_page_counter">Trang 22</span><div class="page_container" data-page="22">

<small>String sameSite) {</small>

<small> StringBuilder = cnew StringBuilder(64+cookie.getValue().length()); c.append(cookie.getName());</small>

<small> c.append( );'='</small>

<small> c.append(cookie.getValue());</small>

<small> append2cookie( ,c"domain", cookie.getDomain()); append2cookie( ,c"path", cookie.getPath()); append2cookie( ,c"SameSite", sameSite);</small>

<small> Calendar expireDate = Calendar.getInstance(); expireDate.setTime(new Date()); expireDate.add(Calendar.SECOND,maxAge);</small>

<small> returnexpiresDateFormat.format(expireDate);</small>

</div><span class="text_page_counter">Trang 23</span><div class="page_container" data-page="23">

Mục đích của class này là tạo chuỗi path thêm vào cookie, thay vì những cách khác là set thẳng từng giá trị vào response thì class <small>HttpService</small> giúp thêm giá trị của SameSite vào một đối tượng cookie đã được tạo. Vì lý do phần code nhóm em set cookie từ một đối tượng cookie.

<small>//response.addCookie(cookieSelector);//response.addCookie(cookieValidator);//response.addCookie(cookieIsLogged);</small>

<small>HttpService.addCookie(response, cookieSelector, "Strict");HttpService.addCookie(response, cookieValidator, "Strict");HttpService.addCookie(response, cookieIsLogged, "Strict");</small>

Phần code này chưa set cho đối tượng JSESSIONID. 1.3 X-Frame-Options Header Not Set

1.3.1 Tấn cơng Clickjacking

Clickjacking là hình thức tấn cơng đánh lừa người dùng nhấn chuột vô ý vào một đối tượng trên website. Một khi nhấn chuột vào một đối tượng trên màn hình, người dùng click vào đối tượng nhưng thực chất đang bị lừa đến một đối tượng khác đã bị ấn hoặc làm mờ đi. Mục đích đánh cắp tài khoản, click vào quảng cáo tăng lượt truy cập để kiếm tiền,…

Rủi ro mà kỹ thuật này gây nên:

- Lấy cắp thông tin thông qua một form fake. - Lừa người dùng mở webcam hoặc microphone. - Phán tán Worms trên các mạng xã hội.

- Phán tán malware bằng cách chuyển hướng người dùng tới link download chương trình độc hại.

- Quảng cáo lừa đảo.

P a g e 17 | 65

</div><span class="text_page_counter">Trang 24</span><div class="page_container" data-page="24">

1.3.2 X-Frame-Opions Header

Vào các trường hợp hacker cố gắng chèn <iframe>, X-Frame-Opions Header giúp ngăn chặn website tránh các tình trạng bị chèn vào các trang website khác. X-Frame-Opions Header dùng để ngăn chặn tấn cơng của Clickjacking.

X-Frame-Opions Header có 3 giá trị:

- X-Frame-Options: DENY - Khơng cho phép bất kì trang nào chèn trang bằng thẻ <iframe>, kể cả trang nằm cùng domain.

- X-Frame-Options: SAMEORIGIN - Khơng cho phép bất kì trang nào chèn trang bằng thẻ <iframe> ngoài trang nằm cùng domain.

- X-Frame-Options: ALLOW-FROM - Không cho phép bất kì trang nào chèn trang bằng thẻ <iframe> ngồi trang another.

Lưu ý, với giá trị allow-from, bạn chỉ có thể chỉ định duy nhất một và chỉ một tên miền thơi, khác với CSP có thể nhận nhiều tên miền hơn.

1.3.3 Xử lý

Tạo packeage package filter và class XframeOptionsFilter

Implement Filter cho class này

<small>public class XFrameOptionsFilter implements Filter{</small>

<small>public void doFilter(ServletRequest servletRequest, ServletResponseservletResponse, FilterChain filterChain)</small>

</div><span class="text_page_counter">Trang 25</span><div class="page_container" data-page="25">

<small>// TODO Auto-generated method stub</small>

<small> HttpServletResponse response = (HttpServletResponse)</small>

<small>@WebFilter("/*") </small>Để áp dụng cho tất cả các trang.

<small>response.addHeader("X-Frame-Options", "DENY"); </small>Để chống tấn công – chống set X-Frame-Options cho response.

1.4 The Cross-Domain JavaScript Source File Inclusion 1.4.1 Khái niệm

- The Cross-Domain JavaScript Source File Inclusion là cảnh báo bảo mật có thể xảy ra khi trang web bao gồm và có khả năng chạy một hoặc nhiều tệp Javascript từ miền của bên thứ ba.

- Nếu tập lệnh không do bạn sở hữu và quản lý, thì có nguy cơ tệp JavaScript được chèn vào của bạn có thể bị thay thế bằng nội dung độc hại, ví dụ: bao gồm mã nguy hiểm hoặc đánh cắp thông tin / tài nguyên nhạy cảm từ người dùng ứng dụng của bạn.

- Trong một số trường hợp, kẻ tấn cơng có thể áp đặt mã hóa UTF-16 mặc dù bộ ký tự của thẻ <script> đã được đặt. Điều này giúp kẻ tấn cơng làm rị rỉ dữ liệu ở các định

P a g e 19 | 65

</div><span class="text_page_counter">Trang 26</span><div class="page_container" data-page="26">

dạng khác nhau như JSON, XML, v.v. Khi người dùng gửi yêu cầu, tập lệnh sẽ được cập nhật cùng với thông báo phản hồi. Nếu phản hồi được lưu trữ trong các biến tồn cục, mọi người đều có thể đọc được. Nếu thông tin nhạy cảm được bao gồm trong phản hồi JSONP, thì hàm được thực thi có thể bị ghi đè để lấy thông tin nhạy cảm. Thủ thuật này cũng có thể được sử dụng cho các chức năng tồn cục. Thay vì ghi đè các hàm đã thực thi, chúng có thể sử dụng các hàm gọi lại được mã hóa tùy chỉnh cho các hàm tồn cục.

- Khi một số tệp JavaScript ứng dụng của bạn nằm trên miền của bên thứ ba và không do bạn quản lý, kẻ tấn cơng có thể cố chiếm đoạt miền đó hoặc truy cập vào máy chủ của bên thứ ba đó để sửa đổi các tệp này và các tệp này có thể thực thi người dùng truy cập vào trang web. Điều này có thể được thực hiện mà không cần truy cập các máy chủ vật lý.

- Tác động của cảnh báo này bao gồm: + Có thể thực thi javascript độc hại

+ Thao tác và rị rỉ dữ liệu người dùng có thể xảy ra + Chức năng có thể thay đổi và chuyển hướng dữ liệu + Nhiễm phần mềm độc hại

- Cụ thể, trong web của nhóm của sự dụng một số <script> từ googleapis, cloudflare bootstrapcdn, và fontawesome

1.4.2 Xử lý

- Nguyên tắc chung để tránh khỏi tấn công từ lỗ hỏng này là luôn lưu trữ tất cả các tệp ứng dụng trên các máy chủ thuộc quyền quản lý hoặc dịch vụ bên thứ ba được công nhận và đáng tin cậy, cơng khai. Những script mà nhóm sử dụng đều từ nguồn được cơng nhận nên có thể n tâm.

- Tránh đặt thông tin nhạy cảm bên trong các các tệp javascript hoặc JSONP

</div><span class="text_page_counter">Trang 27</span><div class="page_container" data-page="27">

1.5. Incomplete or No Cache-control Header Set 1.5.1 Cache-Control là gì ?

- Cache-control là một tiêu đề HTTP được sử dụng để chỉ định các chính sách lưu vào bộ nhớ đệm của trình duyệt trong cả yêu cầu của máy client và phản hồi của máy chủ. Các chính sách bao gồm cách tài nguyên được lưu vào bộ nhớ đệm, nơi lưu trữ tài nguyên và thời gian tồn tại.

- Tiêu đề kiểm soát bộ nhớ cache được chia thành các lệnh, các lệnh phổ biến nhất bao gồm:

+ Cache-Control Max-Age: Chỉ thị yêu cầu thời gian tồn tại xác định, tính bằng giây, lượng thời gian cần để bản sao tài nguyên được lưu trong bộ nhớ cache hết hạn. Sau khi hết hạn, trình duyệt phải làm mới phiên bản tài nguyên của mình bằng cách gửi một yêu cầu khác đến máy chủ. Ví dụ: cache-control: max-age = 120 có nghĩa là tài nguyên trả về có giá trị trong 120 giây, sau đó trình duyệt phải u cầu phiên bản mới hơn.

+ Cache-Control No-Cache: Trình duyệt có thể lưu vào bộ nhớ cache một phản hồi, nhưng trước tiên phải gửi một yêu cầu xác thực đến một máy chủ gốc.

+ Cache-Control No-Store: Các trình duyệt khơng được phép lưu vào bộ nhớ cache một phản hồi và phải lấy nó từ máy chủ mỗi khi nó được yêu cầu. Cài đặt này thường được sử dụng cho dữ liệu nhạy cảm, chẳng hạn như chi tiết ngân hàng cá nhân,… + Cache-Control Public: Một tài nguyên có thể được lưu vào bộ đệm ẩn bởi bất kỳ bộ đệm nào.

+ Cache-Control Private: Một tài nguyên là dành riêng cho người dùng — tài nguyên đó vẫn có thể được lưu vào bộ nhớ cache, nhưng chỉ trên thiết bị khách. Ví dụ: phản hồi trang web được đánh dấu là riêng tư có thể được trình duyệt trên máy tính để bàn lưu vào bộ nhớ cache, nhưng không phải mạng phân phối nội dung (CDN – content delivery network).

1.5.2 Incomplete or No Cache-control Header nguy hiểm như thế nào ?

- Ngay cả sau khi phiên đã đóng, vẫn có thể truy cập vào dữ liệu riêng tư hoặc nhạy cảm được trao đổi trong phiên thơng qua trình duyệt web hoặc proxy cache.

P a g e 21 | 65

</div><span class="text_page_counter">Trang 28</span><div class="page_container" data-page="28">

- Tiêu đề ‘Cache-control’ HTTP chứa các đường dẫn về bộ nhớ đệm trong cả các requests và responses. Tiêu đề ‘Pragma’ được sử dụng để tương thích ngược với HTTP / 1.0 trong khi tiêu đề ‘Cache-control’ không tồn tại.

- Tuy nhiên, Pragma hiện tại đã khơng cịn quan trọng vì nó chỉ tương thích với HTTP/1.0

| Stop using | Replace with | | (HTTP 1.0) | (HTTP 1.1 - 1999) | |--- |--- | | Expires: [date] | Cache-Control: max-age=[seconds] | | Pragma: no-cache | Cache-Control: nocache

1.5.3 Xử lý

Project của nhóm chỉ có Cache-Control ở Request mà khơng có ở Response. - Thiết lập các header để đảm bảo nó ln có trong cả request và response: + Đối với Java Servlet

response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.

response.setHeader("Pragma", "no-cache"); // HTTP 1.0. response.setHeader("Expires", "0"); // Proxies. + Đối với HTML, sử dụng các <meta>

<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />

<meta http-equiv="Pragma" content="no-cache" /> <meta http-equiv="Expires" content="0" />

</div><span class="text_page_counter">Trang 29</span><div class="page_container" data-page="29">

2. Cross-Site Scripting 2.1 Khái niệm

Cross-site scripting là một lỗ hổng phổ biến trong ứng dụng web. Để khai thác một lỗ hổng XSS, hacker sẽ chèn mã độc thông qua các đoạn script để thực thi chúng ở phía client. Có 3 loại Reflected XSS, Stored XSS và DOM-based XSS. Tấn công Cross Site Scripting nghĩa là gửi và chèn lệnh và script độc hại, những mã độc này thường được viết với ngơn ngữ lập trình phía client như Javascript, HTML, VBScript, Flash… Tuy nhiên, cách tấn công này thông thường sử dụng Javascript và HTML.

Nguyên nhân chính của loại tấn cơng này là xác thực đầu vào dữ liệu người dùng không phù hợp, dữ liệu độc hại từ đầu vào có thể xâm nhập vào dữ liệu đầu ra. Mã độc 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 thể biết mã thực thi có phải độc hại hay khơng. Do đó mã độc hại 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.

2.2 Các loại tấn cơng XSS

Có 3 loại tấn cơng XSS chính như sau:

- Reflect XSS : gọi là reflected(phản xạ) bởi vì trong kịch bản khai thác loại này, hacker phải gửi cho nạn nhân một URL có chứa đoạn mã nguy hiểm(thường là javascript). Nạn nhân chỉ cần request đến URL này thì ngay lập tức hacker sẽ nhận được respond chứa kết quả mong muốn(tính phản xạ thể hiện ở đây).

-Stored XSS: khác với Reflected tấn công trực tiếp vào một số 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ỹ các dữ liệu đầu vào trước khi lưu vào cơ sở dữ liệu . Ví dụ như các form góp ý, các comment … trên các trang web. Với kỹ thuật Stored XSS , hacker không khai thác trực tiếp mà phải thực hiện tối thiểu qua 2 bước.

- 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.Trong DOM-based XSS attack, chuỗi độc hại không thực sự

P a g e 23 | 65

</div><span class="text_page_counter">Trang 30</span><div class="page_container" data-page="30">

được xử lý bởi trình duyệt nạn nhân cho đến khi JavaScript hợp pháp của website được thực thi.

2.3 Giải pháp ngăn chặn

Các phương pháp phòng ngừa chính được sử dụng phổ biến bao gồm: data validation, filtering, escaping. Bước đầu tiên trong cơng tác phịng chống tấn công này là xác thực đầu vào. Mọi thứ, được nhập bởi người dùng phải được xác thực chính xác. Xác thực dữ liệu có thể được đặt tên làm cơ sở để đảm bảo tính bảo mật của hệ thống, nhưng có thể khơng đủ để ngăn chặn lỗ hổng XSS có thể xảy ra.

Một phương pháp ngăn chặn tốt khác là lọc đầu vào của người dùng. Ý tưởng lọc là tìm kiếm các từ khóa nguy hiểm trong mục nhập của người dùng và xóa chúng hoặc thay thế chúng bằng các chuỗi trống. Những từ khóa đó có thể là: thẻ <script> </ script>,lệnh Javascript , đánh dấu HTML.

- Giảm thiểu DOM-Based XSS Server-Side

Sử dụng JavaScript Framework: các Frameworks như Ember, AngularJS và React sử dụng các template đã kiểm tra các cuộc tấn cơng XSS có thể xảy ra và làm sạch input của người dùng.

Audit Code cẩn thận: nếu bạn đang sử dụng native DOM APIs, hãy tránh sử dụng các thuộc tính và chức năng sau: InnerHTML, outerHTML, document.write .Thay vào đó, hãy đặt nội dung văn bản trong các tag bất cứ nơi nào có thể: InnerText, textContent

Giảm thiểu Client side DOM-based XSS chỉ có thể thơng qua việc cập nhật trình duyệt hỗ trợ hạn chế chính sách CORS và CSP mới nhất, ngăn người dùng nhấp vào các liên kết đáng ngờ.

</div><span class="text_page_counter">Trang 31</span><div class="page_container" data-page="31">

2.4 Tấn công project với XSS 2.4.1 Tấn công

Chèn các đoạn script vào những nơi có nhập input người dùng như comment bài viết, thanh tìm kiếm, tạo bài viết, hệ thống web đều thực thi những đoạn lệnh này do chưa có kiểm tra lọc đầu vào hợp lệ. Như vậy hệ thống bị tấn công dạng Store XSS , những đoạn mã bị lưu dưới database khi nhập vào comment, và mỗi khi người dùng load một bài viết nào có comment như vậy đều sẽ bị tấn cơng. Như hình dưới đây:

Nhấn nút bình luận, ta sẽ thấy xuất hiện alert thông tin lưu trong cookie của người dùng. Và mỗi khi bất kì người dùng nào click vào chi tiết bài viết này, những bình luận sẽ được load lên và kể cả comment chưa đoạn script này. Vì nó đã được lưu trữ dưới database.

</div><span class="text_page_counter">Trang 32</span><div class="page_container" data-page="32">

khác như &lt; , &quot; ,…

Thêm escapeHtml() khi lấy parameter nội dung comment từ phía client trong class commentController

</div>