Báo cáo đề tài bảo mật web website chia sẻ thông tin dành cho it

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ó toàn quyền quản lí website, cấp quyền

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.

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)

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ể hoà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

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

4.3 NoSQL Injection wordlists 39

4.4 Lý giải nguyên do không có lỗ hổng MongoDB NoSQL Injection trong ứng dụng 47

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

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

18110285 Nguyễn Thị Minh Hoà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

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ó toà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

2 Lược đồ usecase

P a g e 3 | 65

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

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

- Link project: https://github.com/4fit/x4fit - 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

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

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

https://drive.google.com/drive/folders/1MFfMBLlX7gfIDbAO4IVMa3PcJxaBqxuu? usp=sharing

P a g e 7 | 65

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

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

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

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:

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>

Toà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

if ( account_id != null) {

//L uư cookie

String selector = RandomStringUtils.randomAlphanumeric(12);String rawValidator = RandomStringUtils.randomAlphanumeric(64);String hashedValidator = DigestUtils.sha256Hex(rawValidator);

Authentication auth = new Authentication(account_id selector, ,

Cookie cookieSelector = new Cookie("selector", selector);

Cookie cookieValidator = new Cookie("validator",

P a g e 13 | 65

Cookie cookieIsLogged = new Cookie("is_logged" "true", );

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

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 HttpService

FastDateFormat.getInstance("EEE, dd MMM yyyy HH:mm:ss zzz",

P a g e 15 | 65

String sameSite) {

StringBuilder = cnew StringBuilder(64+cookie.getValue().length()); c.append(cookie.getName());

c.append( );'='

c.append(cookie.getValue());

append2cookie( ,c"domain", cookie.getDomain()); append2cookie( ,c"path", cookie.getPath()); append2cookie( ,c"SameSite", sameSite);

Calendar expireDate = Calendar.getInstance(); expireDate.setTime(new Date()); expireDate.add(Calendar.SECOND,maxAge);

returnexpiresDateFormat.format(expireDate);

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 HttpService 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.

//response.addCookie(cookieSelector);//response.addCookie(cookieValidator);//response.addCookie(cookieIsLogged);

HttpService.addCookie(response, cookieSelector, "Strict");HttpService.addCookie(response, cookieValidator, "Strict");HttpService.addCookie(response, cookieIsLogged, "Strict");

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

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 https://another-domain.com - Không cho phép bất kì trang nào chèn trang bằng thẻ <iframe> ngoà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

public class XFrameOptionsFilter implements Filter{

public void doFilter(ServletRequest servletRequest, ServletResponseservletResponse, FilterChain filterChain)

// TODO Auto-generated method stub

HttpServletResponse response = (HttpServletResponse)

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

response.addHeader("X-Frame-Options", "DENY"); Để 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

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 toà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 toà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 toà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ể yê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

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 yê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

- 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ó luôn 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" />

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

đượ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ờ.

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.

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

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