1. Trang chủ
  2. » Giáo Dục - Đào Tạo

BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP

83 20 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Bộ Bài Hướng Dẫn Thực Hành Khai Thác Lỗ Hổng Ứng Dụng Web Trên BWAPP
Trường học Học Viện Kỹ Thuật Mật Mã
Năm xuất bản 2019
Thành phố Hà Nội
Định dạng
Số trang 83
Dung lượng 3,52 MB

Cấu trúc

  • Mục lục

  • Danh mục kí hiệu và viết tắt

  • Danh mục hình vẽ

  • Chương 1. KỸ THUẬT TẤN CÔNG SQL INJECTION

    • 1.1. Nhận diện điểm yếu SQL Injection trong ứng dụng web

      • 1.1.1. Xác định lỗ hổng trong việc kiểm tra thông tin đầu vào

      • 1.1.2. Xác định điểm yếu SQL Injection dựa trên phản hồi

        • a) Xác định các điểm nhận nhập vào từ người dùng

        • b) Các hình thức thông báo lỗi thường gặp

    • 1.2. Tấn công khai thác dữ liệu thông qua toán tử UNION

      • 1.2.1. Tổng quan về toán tử UNION

      • 1.2.2. Tìm số cột và kiểu dữ liệu của cột

      • 1.2.3. Tìm cột có khả năng chứa thông tin khai thác được

      • 1.2.4. Xác định tên của các bảng

      • 1.2.5. Xác định tên các cột trong bảng

      • 1.2.6. Thu thập các dữ liệu quan trọng

    • 1.3. Khai thác thông qua các câu lệnh điều kiện

      • 1.3.1. Tổng quan về khai thác thông qua các câu lệnh điều kiện

      • 1.3.2. Mô hình dựa trên nội dung phản hồi

      • 1.3.3. Mô hình dựa trên độ trễ phản hồi

    • 1.4. Blind SQL Injection – phương thức tấn công nâng cao

      • 1.4.1. Tổng quan về Blind SQL Injection

      • 1.4.2. Tấn công Blind SQL Injection dựa trên phản hồi

      • 1.4.3. Tấn công Blind SQL Injection dựa trên độ trễ truy vấn

      • 1.4.4. Lợi dụng điểm yếu Blind SQL Injection để khai thác thông tin trong thực tế

    • 1.5. Bộ bài hướng dẫn các tấn công SQL Injection

      • 1.5.1. SQL Injection (Login Form/Hero)

      • 1.5.2. SQL Injection (GET/Search)

      • 1.5.3. SQL Injection (POST/Search)

      • 1.5.4. SQL Injection – Blind – Boolean Based

      • 1.5.5. SQL Injection – Blind – Time Based

  • Chương 2. KỸ THUẬT TẤN CÔNG XSS

    • 2.1. Tấn công XSS

      • 2.1.1. Xác định lỗi XSS

      • 2.1.2. Các bước thực hiện khai thác lỗi XSS

    • 2.2. Bộ bài hướng dẫn các tấn công XSS

      • 2.2.1. Thực hành tấn công XSS phản xạ sử dụng phương thức GET mức độ dễ

      • 2.2.2. Thực hành tấn công XSS phản xạ sử dụng phương thức GET mức độ trung bình

      • 2.2.3. Thực hành tấn công XSS phản xạ sử dụng phương thức POST mức độ dễ

      • 2.2.4. Thực hành tấn công XSS phản xạ sử dụng phương thức POST mức trung bình

      • 2.2.5. Thực hành tấn công XSS phản xạ sử dụng chuỗi JSON mức dễ

      • 2.2.6. Thực hành tấn công XSS phản xạ sử dụng thuộc tính HREF mực độ dễ

      • 2.2.7. Thực hành tấn công XSS phản xạ sử dụng hàm EVAL mức độ dễ

      • 2.2.8. Thực hành tấn công XSS lưu trữ dạng Blog mức độ dễ

  • Chương 3. Kỹ Thuật TẤN CÔNG CSRF

    • 3.1. Cross-site Request Forgery

      • 3.1.1. Xác định lỗi CSRF

      • 3.1.2. Các bước thực hiện khai thác lỗi CSRF

    • 3.2. Bộ bài hướng dẫn các tấn công CSRF

      • 3.2.1. Thực hành tấn công CSRF (Change Password) mức độ dễ

      • 3.2.2. Thực hành tấn công CSRF (Transfer Amount) mức độ dễ

  • Tài liệu tham khảo

  • Phụ lục

Nội dung

KỸ THUẬT TẤN CÔNG SQL INJECTION

Nhận diện điểm yếu SQL Injection trong ứng dụng web

Xác định điểm yếu là bước đầu tiên quan trọng để khắc phục lỗ hổng SQL Injection trong ứng dụng Quá trình này được thực hiện tương tự như cách mà hacker tiến hành thăm dò và phát hiện lỗi SQL Injection.

1.1.1 Xác định lỗ hổng trong việc kiểm tra thông tin đầu vào

Các tham số nhập vào sẽ được sử dụng để tạo ra các truy vấn SQL, do đó cần phải tuân thủ các quy tắc cú pháp liên quan đến các thành phần trước và sau trong truy vấn gốc Dưới đây là đoạn mã PHP để xử lý đăng nhập.

$uname = isset($_POST[‘uname’]) ? $_POST[‘uname’] : “”; $passwd=isset($_POST[‘passwd’]) ? $_POST[‘passwd’] : “”;

$query = “SELECT * FROM tbl_users WHERE username = ”” +

Xâu truy vấn SQL được tạo ra từ giá trị người dùng nhập vào được gọi là truy vấn động (dynamic query) Truy vấn này sẽ có dạng như sau:

SELECT * FROM tbl_users WHERE username=’$uname’ AND password=’$passwd’;

Khi người dùng nhập hai giá trị $name và $passwd, nếu giá trị username được nhập là 'admin' or '1'='1', truy vấn động sẽ được thực hiện như sau.

SELECT * FROM tbl_users WHERE username=’admin’ or ‘1’=’1’ AND password=”;

Truy vấn này tuy có cụm luôn đúng, nhưng do toán tử AND có độ ưu tiên cao hơn OR do đó truy vấn trên tương đương với:

SELECT * FROM tbl_users WHERE username=’admin’ or ‘1’=’1’ AND password=” or ‘1’=’1’;

Truy vấn trên tương đương với:

SELECT * FROM tbl_users WHERE username=’admin’ or password=” or

Trong trường hợp này, việc xác thực đã thành công vì mệnh đề WHERE luôn đúng Ngoài ra, chúng ta có thể thêm đoạn mã 'or '1'='1' vào trường username, ví dụ như 'admin' or '1'='1', và kết quả vẫn sẽ tương tự, do toán tử AND đã được khử trước các toán tử OR.

Tùy thuộc vào câu truy vấn gốc, vị trí của các tham số được chèn vào sẽ khác nhau Mỗi trường hợp tương ứng với các mô hình chèn tham số riêng biệt.

Chèn vào giữa truy vấn là mô hình chỉ thao tác với tham số mà không ảnh hưởng đến cấu trúc và các thành phần của truy vấn gốc Mô hình này có thể được khái quát như sau:

Hình 1.1 Mô hình chèn vào giữa truy vấn

Chèn và ngắt truy vấn là mô hình chèn truy vấn phổ biến nhất, trong đó truy vấn được chèn vào sẽ bao gồm các ký tự comment ở cuối để ngắt truy vấn, vô hiệu hóa các phần tử trong truy vấn gốc phía sau vị trí tham số Đoạn mã PHP đã được cải tiến để nâng cao hiệu quả và bảo mật.

$uname = isset($_POST[‘uname’] ? $_POST[‘uname’] : “”;

$passwd=isset($_POST[‘passwd’]) ? $_POST[‘passwd’] : “”; if($uname ==”” || passwd ==””){ echo “username or password id missing”;

}else{ if($passwd ==””) echo “password is missing”; else if($uname ==””) echo “username id missing”;

$query = “SELECT * FROM tbl_users WHERE username = ”” + $uname

Để đảm bảo các trường username và password không để trống, ta chỉ cần kiểm tra sự tồn tại của giá trị trong hai trường này Thay vì sử dụng nhiều mệnh đề OR, có thể sử dụng comment để ngắt truy vấn ngay sau khi gặp mệnh đề OR 1=1 đầu tiên Ví dụ, với username để trống và password bất kỳ (khác rỗng), truy vấn sẽ được cấu trúc như sau:

SELECT * FROM tbl_users WHERE username =’admin’ or 1=1;

Và với truy vấn này hacker qua mặt được xác thực do mệnh đề WHERE luôn đúng Một số ký tự comment hay dùng:

Hình 1.2 Các ký tự comment thường gặp

1.1.2 Xác định điểm yếu SQL Injection dựa trên phản hồi Để thực hiện, cần tối thiểu là một trình duyệt web, có thể trang bị thêm một số ứng dụng Proxy (ví dụ Burp proxy, Hackbar,…) và tiến hành các phép thử SQL Injection ngẫu nhiên và tiến hành phân tích, thống kê kết quả a) Xác định các điểm nhận nhập vào từ người dùng

Trong mô hình Client/Server trên môi trường web, trình duyệt web đóng vai trò là điểm nhận nhập vào từ người dùng Các phương thức nhập liệu phổ biến từ client bao gồm đường dẫn (link), khung nhập liệu (form) và cookie Khi người dùng gửi dữ liệu, trình duyệt sẽ tạo ra một yêu cầu HTTP gửi đến web server, với hai phương thức yêu cầu phổ biến nhất là GET và POST.

Cấu trúc thông điệp GET và POST có sự khác biệt rõ rệt, đặc biệt khi thực hiện việc sửa đổi và chèn nội dung Một yếu tố quan trọng cần lưu ý là vị trí của chuỗi truy vấn (query string), nơi chứa các tham số được gửi đến web server Chuỗi truy vấn có định dạng như sau: ?var_1=val_1&var_2&…&var_n=val_n.

Trong thông điệp GET chuỗi truy vấn nằm ở đầu thông điệp, còn trong POST nó nằm ở cuối thông điệp

Xét một trang thông tin có đường dẫn: http://www.demohack.com/category_index.php

Trang web chứa các liên kết dẫn đến nhiều danh mục thông tin khác nhau, bao gồm tin nóng, tin thế giới và tin địa phương Khi nhấn vào các liên kết như http://www.demohack.com/category_index.php?cat_name=tin_nong, http://www.demohack.com/category_index.php?cat_name=tin_the_gioi, và http://www.demohack.com/category_index.php?cat_name=tin_dia_phuong, người dùng sẽ được chuyển đến những trang tương ứng với nội dung mà họ quan tâm.

Khi gửi yêu cầu GET, chuỗi truy vấn hiển thị trên trình duyệt với tham số cat_name, dẫn đến nội dung trả về khác nhau Để phát hiện lỗi SQL Injection trong ứng dụng web, người ta thường thêm các ký tự meta như dấu nháy đơn, dấu nháy kép, dấu chấm phẩy và ký tự comment vào câu truy vấn, sau đó quan sát cách ứng dụng xử lý chúng.

Sau khi thử thêm dấu nháy đơn (‘) vào cuối giá trị tham số cat_name, ta có kết quả trả về cho đường dẫn:

Có những dấu hiệu bất thường trong phản hồi liên quan đến các giá trị tham số được điều chỉnh khác nhau Ngoài ra, cũng có nhiều hình thức thông báo lỗi thường gặp mà người dùng cần lưu ý.

Tấn công khai thác dữ liệu thông qua toán tử UNION

1.2.1 Tổng quan về toán tử UNION

Khai thác thông tin bằng cách sử dụng UNION là một trong hai phương pháp chính trong việc khai thác dữ liệu qua lỗi SQL Injection Các lỗ hổng SQL Injection có thể bị lợi dụng thông qua UNION, cho phép thông tin trả về hiển thị trực tiếp trên phản hồi.

Toán tử UNION cho phép ghép dữ liệu từ hai truy vấn, nhưng yêu cầu cả hai phải có số cột và kiểu dữ liệu tương đồng Để thực hiện khai thác qua UNION, cần trải qua hai giai đoạn: đầu tiên là xác định số lượng và kiểu dữ liệu của các cột, sau đó là tìm ra cột nào có khả năng chứa thông tin từ truy vấn khai thác.

1.2.2 Tìm số cột và kiểu dữ liệu của cột

Trong bài viết này, chúng ta sẽ xem xét một lỗ hổng SQL Injection trên biến product_id thông qua đường dẫn: http://www.demohack.com/user/productdetails.php?product_id Để xác định số cột của bảng hiện tại, có hai phương pháp có thể sử dụng, đó là UNION hoặc ORDER BY Giả định rằng truy vấn của ứng dụng được xây dựng để trả về kết quả hiện tại.

SELECT * FROM tbl_product WHERE product_id;

Mệnh đề ORDER BY trong SQL được sử dụng để sắp xếp kết quả của truy vấn theo cột được chỉ định Nếu cột không tồn tại, hệ thống sẽ trả về thông báo lỗi Ví dụ, để sắp xếp theo cột thứ hai, bạn có thể sử dụng tham số ORDER BY 2 trong truy vấn của mình, như trong ví dụ sau:

SELECT * FROM tbl_product WHERE product_id ORDER BY 2 -;

Nếu không có lỗi trả về và bảng hiện tại có ít nhất 2 cột, ta có thể tiếp tục tăng số cột dự đoán Chiến thuật đoán này có thể áp dụng tìm kiếm nhị phân, trong đó ta xác định hai mốc lớn nhất và nhỏ nhất để tìm kiếm giữa chúng Ví dụ, khi thử với mốc 10 cột, nếu nhận được lỗi "Unknown column ‘10’ in ‘order clause’", điều này cho thấy cần điều chỉnh số cột dự đoán.

Tiếp tục tìm kiếm nhị phân giữa hai mốc 2 và 10 ta tìm được số cột là 7

1.2.3 Tìm cột có khả năng chứa thông tin khai thác được

Mục đích của công việc này là xác định cột có nội dung hiển thị trên phản hồi và nhúng thông tin khai thác vào đó Để thực hiện điều này, cần sử dụng các nội dung mang tính "chỉ điểm" cho cột có thể khai thác được.

SELECT * FROM tbl_product WHERE product_id=1 UNION SELECT

Nếu phát hiện bất kỳ con số nào trong các giá trị "chỉ điểm" xuất hiện bất thường trong phản hồi, điều này cho thấy cột đó có thể chứa thông tin có thể khai thác.

Cột số 2, 3, 4, 5 có thể được sử dụng để thu thập thông tin khai thác Để kiểm chứng, ta thay giá trị 2 bằng version(), giá trị 3 bằng database(), và giá trị 4 bằng user(), từ đó lần lượt xác định phiên bản SQL, tên cơ sở dữ liệu, và tên người dùng hiện tại của ứng dụng.

1.2.4 Xác định tên của các bảng

Tiếp tục, chúng ta thay thế giá trị 5 bằng câu lệnh `group_concat(table_name)` và thêm `from information_schema.tables where table_schema=database() ` vào cuối truy vấn Mục đích là để lấy tên tất cả các bảng có trong cơ sở dữ liệu, và kết quả thu được như sau:

1.2.5 Xác định tên các cột trong bảng

Bảng users là bảng quan trọng nhất trong cơ sở dữ liệu, vì nó chứa thông tin cá nhân của người dùng Do đó, chúng ta sẽ tiến hành lấy tên các cột của bảng users để phục vụ cho các mục đích quản lý và phân tích dữ liệu hiệu quả hơn.

Thay vào group_concat(column_name) và cuối xâu truy vấn thêm from information_schema.columns where table_name=‘users’ , ta thu được kết quả:

1.2.6 Thu thập các dữ liệu quan trọng

Chúng ta đã xác định được các cột quan trọng trong bảng users, bao gồm login, password và email Bằng cách sử dụng hàm group_concat với cú pháp login, 0x3a, password, 0x3a, email, và chỉnh sửa câu truy vấn thành "from users ", chúng ta có thể thu thập được thông tin cần thiết.

Khai thác thông qua các câu lệnh điều kiện

1.3.1 Tổng quan về khai thác thông qua các câu lệnh điều kiện Ý tưởng chung của dạng tấn công dựa trên các câu lệnh điều kiện này chính là khiến cho database trả về những trạng thái khác nhau phụ thuộc vào từng điều kiện được đưa ra Mỗi điều kiện đưa ra đó có thể giúp suy ra được từng bit của một byte dữ liệu cụ thể Việc đi sâu vào dạng tấn công này sẽ được đề cập ở mục Blind SQL Injection, hiện tại ta sẽ đề cập tới nguyên tắc chung của nó

Một truy vấn dựa vào điều kiện sẽ có dạng như một câu lệnh điều kiện trên các ngôn ngữ lập trình ứng dụng thông thường, có dạng:

IF điều_kiện THEN chuỗi_xứ_lý_đúng ELSE chuỗi_xử_lý_sai

Trên các DBMS cụ thể, có một số truy vấn dạng trên:

IF(biểu_thức_boolean) SELECT trường_hợp_đúng ELSE trường_hợp_sai

- Trên MySQL: SELECT IF(biểu_thức_boolean,TH_đúng,TH_sai)

SELECT CASE WHEN biểu_thức_boolean THEN trường_hợp_đúng ELSE trường_hợp_sai END FROM DUAL

Mệnh đề biểu thức boolean, hay còn gọi là mệnh đề suy luận, yêu cầu xác định kết quả trả về khi mệnh đề đúng và khi mệnh đề sai Việc phân biệt kết quả trong hai trường hợp này là một vấn đề quan trọng cần giải quyết Một số mô hình đã được nghiên cứu và áp dụng để phân loại kết quả cho từng tình huống.

+ Mô hình dựa trên nội dung phản hồi

+ Mô hình dựa trên độ trễ phản hồi

1.3.2 Mô hình dựa trên nội dung phản hồi Đầu tiên ta cần làm rõ tên gọi của mô hình này Phản hồi ở đây chính là nội dung kết quả truy vấn được cơ sở dữ liệu trả về Mô hình dựa trên phản hồi này sẽ dựa trên sự khác biệt về nội dung phản hồi so với trường hợp nào đó tương đồng để suy ra đúng

Thông báo lỗi là trường hợp dễ nhận biết nhất, bởi vì chúng có thời gian thực thi truy vấn nhanh chóng Các lỗi này thường được phát hiện trong quá trình phân tích cú pháp của truy vấn, trước khi được thực thi trong cơ sở dữ liệu, dẫn đến thời gian phản hồi nhanh.

Trong trường hợp tham số kiểu số (numeric), một mệnh đề suy luận có thể trả về giá trị 0 Một ví dụ điển hình là lỗi khi thực hiện phép chia cho 0 Để minh họa, ta có thể sử dụng mệnh đề suy luận liên quan đến tên người dùng hiện tại trong cơ sở dữ liệu MySQL: http://site/products.php?id0/(select if((substr(user(),1,5) like 'admin%'),1,0)).

Nếu người dùng hiện thời có username bắt đầu bởi cụm “admin” thì id có giá trị là 32 chia cho 1, ngược lại là 32 chia cho 0 (sinh lỗi)

Có thể biểu diễn URL trên ở một dạng khác như sau: http://site/products.php?id=if((substr(user(),1,5) like

Việc xử lý sinh lỗi trong mệnh đề suy luận không quan trọng, vì nó đã được thể hiện rõ ràng trong cú pháp của câu lệnh điều kiện.

Các lỗi trả về có thể tiết kiệm thời gian, nhưng thường bị quản trị web vô hiệu hóa hoặc dẫn đến trang mặc định, làm khó khăn trong việc xác định kết quả suy luận Thay vì tạo ra lỗi, có thể sinh một truy vấn hợp lệ với kết quả khác so với truy vấn ban đầu của ứng dụng.

Request ban đầu: http://site/products.php?id http://site/search.php?key=laptop

The article discusses a phishing attempt that seeks to obtain the current username by exploiting vulnerabilities in a website's product and search pages The malicious URLs include SQL injection techniques to check if the username contains "admin" and potentially return sensitive information It's crucial for website owners to implement robust security measures to protect against such attacks.

Truy vấn giả mạo thứ nhất thay đổi mã sản phẩm sẽ được hiển thị, và truy vấn thứ hai thay đổi giá trị từ khoá tìm kiếm

1.3.3 Mô hình dựa trên độ trễ phản hồi

Mô hình này, được biết đến với tên gọi mô hình dựa trên thời gian, dựa vào sự khác biệt về thời gian nhận phản hồi từ cơ sở dữ liệu server Khác với phương pháp nhận biết sự khác biệt nội dung phản hồi, mô hình này không chú ý đến nội dung của truy vấn trả về, vì vậy các cấu hình chặn và xử lý thông báo lỗi của quản trị viên không ảnh hưởng đến phương pháp này.

Độ trễ thực thi của truy vấn chính thường phát sinh từ các hàm thực hiện hoãn hoặc do việc xử lý một lượng lớn truy vấn phụ.

In MySQL, the SLEEP function can be utilized in requests to introduce a delay that distinguishes between true and false conditions in logical statements For instance, the following request demonstrates this application: http://site/products.php?id=if((substring(version(),1,1)=’5’),sleep(5),20).

Khi thực hiện yêu cầu để suy luận phiên bản MySQL, nếu ký tự đầu tiên trong phiên bản là 5 (tức MySQL 5), hệ thống sẽ hoãn phản hồi trong 5 giây thông qua hàm sleep(5) Ngược lại, nếu phiên bản khác, hệ thống sẽ trả về giá trị id là 20 ngay lập tức Việc so sánh thời gian hoàn thành truy vấn với trường hợp bình thường giúp xác định thông tin về phiên bản MySQL đang sử dụng.

Ngoài việc sử dụng các hàm có sẵn trên DBMS để sinh độ trễ, một phương pháp khả thi hơn là thực hiện các truy vấn tốn chi phí thực thi cao, chẳng hạn như các phép truy vấn trên từ điển dữ liệu (data dictionary hay metadata) Những vấn đề cụ thể liên quan đến mô hình này sẽ được thảo luận trong phần về Blind SQL Injection.

Blind SQL Injection – phương thức tấn công nâng cao

1.4.1 Tổng quan về Blind SQL Injection

Blind SQL Injection là một kỹ thuật tấn công SQL Injection khi thông tin không được hiển thị trực tiếp trong phản hồi từ cơ sở dữ liệu Phương pháp này dựa vào việc sử dụng các mệnh đề điều kiện để suy luận thông tin cần khai thác Cụ thể, Blind SQL Injection áp dụng các thông tin cần khai thác làm mệnh đề điều kiện và sử dụng các phương pháp khác nhau để xác định tính đúng/sai của các mệnh đề này.

Căn cứ vào phương pháp đánh dấu trường hợp đúng/sai của mệnh đề quan hệ, ta chia ra hai cách chính thực hiện Blind SQL Injection:

- Dựa vào nội dung phản hồi (response-based)

- Dựa vào độ trễ của thời gian phản hồi (time-based)

Các phương pháp thực hiện Blind SQL Injection có thể áp dụng cho nhiều mô hình khác mà không gặp khó khăn, nhưng chi phí về thời gian và số lượng truy vấn cần thiết sẽ luôn cao hơn.

1.4.2 Tấn công Blind SQL Injection dựa trên phản hồi

Trong bài viết này, chúng ta sẽ minh hoạ một dạng tấn công trên WebGoat, với mục tiêu tìm thuộc tính first_name của người dùng có mã userid 15643 Chúng ta sẽ kiểm tra xem số tài khoản có hợp lệ hay không, với kết quả trả về là "Valid account number" nếu đúng, hoặc "Invalid account number" nếu sai Bảng dữ liệu tham chiếu trong trường hợp này là user_data.

Tình huống cho phép chúng ta đoán truy vấn SQL được xây dựng có dạng:

SELECT * FROM user_data WHERE userid = $user_input;

Khía cạnh “blind” trong trường hợp này thể hiện ở việc chúng ta chỉ có thể nhận diện hai trạng thái trả về duy nhất, mà không có bất kỳ thông tin hay nội dung nào khác được tiết lộ trong thông điệp phản hồi.

Chúng tôi tiến hành xây dựng các mệnh đề suy luận để xác định từng ký tự trong username của người dùng có userid 15643 Miền giá trị cần tìm kiếm là các ký tự từ a-zA-Z, phù hợp với đặc điểm tên người Để thuận tiện cho việc so sánh trong các mệnh đề suy luận, chúng tôi thực hiện thao tác với từng ký tự thông qua mã ASCII của chúng Đối với ký tự đầu tiên, chúng tôi biểu diễn nó như sau:

Ascii(substring(SELECT first_name FROM user_data WHERE userid= 15613,1,1))

Truy vấn SQL sẽ trả về giá trị first_name của userid 15613, trong khi hàm substring(string, begin, length) được sử dụng để lấy ký tự đầu tiên trong chuỗi Đồng thời, hàm ascii(character) sẽ trả về mã ASCII của ký tự đầu tiên đang được xem xét.

Mệnh đề truy vấn được thực hiện bằng cách so sánh giá trị ASCII với các mốc A(65), Z(90), a(97), z(122) Để tiết kiệm chi phí cho việc sinh truy vấn, chúng ta áp dụng nguyên tắc tìm kiếm nhị phân.

- Ban đầu so sánh giá trị cần tìm với Z để kết luận đó là chữ hoa hay chữ thường

- Nếu là chữ hoa, tìm kiếm nhị phân trong khoảng 65 tới 90, ngược lại, tìm trong khoảng 97 tới 112

Nếu gặp một ký tự không thỏa mãn các điều kiện đã nêu, kết luận rằng quá trình tìm kiếm đã hoàn tất, vì ký tự đó không có trong chuỗi và chúng ta đã kiểm tra toàn bộ chuỗi cần tìm.

Thực hiện nhập tham số userid như bình thường, khi submit, sử dụng ứng dụng proxy để sửa nội dung tham số

- Thử kiểm tra ký tự đầu tiên trong first_name, tham số được giả mạo sẽ là:

15613 and ascii(substring(select first_name from user_data where userid613,1,1))

Ngày đăng: 19/10/2021, 19:08

HÌNH ẢNH LIÊN QUAN

Hình 1.2 Các ký tự comment thường gặp 1.1.2. Xác định điểm yếu SQL Injection dựa trên phản hồi  - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 1.2 Các ký tự comment thường gặp 1.1.2. Xác định điểm yếu SQL Injection dựa trên phản hồi (Trang 10)
Hình 1.4 Truy vấn ban đầu - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 1.4 Truy vấn ban đầu (Trang 21)
Hình 1.12 Kết quả thu được trong tấn công SQL Injection (GET/Search) 1.5.3.SQL Injection (POST/Search)  - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 1.12 Kết quả thu được trong tấn công SQL Injection (GET/Search) 1.5.3.SQL Injection (POST/Search) (Trang 27)
Hình 1.13 Chọn bài tập tấn công SQL Injection (POST/Search) - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 1.13 Chọn bài tập tấn công SQL Injection (POST/Search) (Trang 27)
Hình 1.14 Giao diện bài tập tấn công SQL Injection (POST/Search) - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 1.14 Giao diện bài tập tấn công SQL Injection (POST/Search) (Trang 28)
Tiếp tục, tại khung chọn “Proxy Listeners” chọn “Add” và xuất hiện bảng “Add a new proxy listener”  - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
i ếp tục, tại khung chọn “Proxy Listeners” chọn “Add” và xuất hiện bảng “Add a new proxy listener” (Trang 29)
Hình 1.27 Trạng thái trả về bị trễ trong Blind – Time Based - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 1.27 Trạng thái trả về bị trễ trong Blind – Time Based (Trang 37)
Hình 2.1 Các bước thực hiện khai thác lỗi XSS - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 2.1 Các bước thực hiện khai thác lỗi XSS (Trang 45)
Hình 2.2 Chọn bài XSS- Reflected (GET) - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 2.2 Chọn bài XSS- Reflected (GET) (Trang 47)
Hình 2.7 Kết quả kiểm tra lỗi XSS trong bài thực hành XSS- Reflected (GET) mức độ dễ  - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 2.7 Kết quả kiểm tra lỗi XSS trong bài thực hành XSS- Reflected (GET) mức độ dễ (Trang 49)
Hình 2.8 Up 2 file get.php và get.txt thành công lên host - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 2.8 Up 2 file get.php và get.txt thành công lên host (Trang 50)
Hình 2.9 File html đánh lừa người dùng kick vào - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 2.9 File html đánh lừa người dùng kick vào (Trang 51)
Hình 2.10 Cookie sau khi lấy được của người dùng - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 2.10 Cookie sau khi lấy được của người dùng (Trang 51)
Hình 2.19 Kết quả kiểm tra thành công lỗi XSS trong bài XSS- Reflected (POST) mức độ dễ  - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 2.19 Kết quả kiểm tra thành công lỗi XSS trong bài XSS- Reflected (POST) mức độ dễ (Trang 55)
Hình 2.26 Nhập dữ liệu vào ô search trong bài XSS- Reflected (JSON) mức độ dễ - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 2.26 Nhập dữ liệu vào ô search trong bài XSS- Reflected (JSON) mức độ dễ (Trang 58)
Hình 2.28 Kết quả kiểm tra lỗi XSS trong bài XSS- Reflected (JSON) mức độ dễ - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 2.28 Kết quả kiểm tra lỗi XSS trong bài XSS- Reflected (JSON) mức độ dễ (Trang 59)
Hình 2.30 Chọn level low trong bài XSS- Reflected (HREF) - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 2.30 Chọn level low trong bài XSS- Reflected (HREF) (Trang 60)
Hình 2.29 Chọn bài XSS- Reflected (HREF) - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 2.29 Chọn bài XSS- Reflected (HREF) (Trang 60)
Hình 2.33 Kết quả trả về khi nhập 1 đoạn javascript trong bài XSS- Reflected (HREF) mức độ dễ  - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 2.33 Kết quả trả về khi nhập 1 đoạn javascript trong bài XSS- Reflected (HREF) mức độ dễ (Trang 61)
Hình 2.35 Chọn bài XSS- Reflected (Eval) - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 2.35 Chọn bài XSS- Reflected (Eval) (Trang 63)
Hình 2.36 Chọn level low trong bài XSS- Reflected (Eval) Xác định lỗi XSS  - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 2.36 Chọn level low trong bài XSS- Reflected (Eval) Xác định lỗi XSS (Trang 63)
Hình 2.43 Kết quả trả về khi nhập dữ liệu gửi lên server trong bài XSS- Stored (Blog) mức độ dễ  - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 2.43 Kết quả trả về khi nhập dữ liệu gửi lên server trong bài XSS- Stored (Blog) mức độ dễ (Trang 66)
Hình 3.1 Các bước thực hiện khai thác lỗi CSRF - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 3.1 Các bước thực hiện khai thác lỗi CSRF (Trang 71)
Hình 3.2 Mô hình tấn công CSRF theo phương thức POST - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 3.2 Mô hình tấn công CSRF theo phương thức POST (Trang 72)
Hình 3.3 Chọn bài CSRF (Change Password) - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 3.3 Chọn bài CSRF (Change Password) (Trang 73)
Hình 3.5 Giao diện thực hiện tấn công CSRF trong bài CSRF (Change Password) mức độ dễ  - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 3.5 Giao diện thực hiện tấn công CSRF trong bài CSRF (Change Password) mức độ dễ (Trang 74)
Hình 3.7 Sử dụng chức năng Generate CSRF PoC trên Burp Suite - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 3.7 Sử dụng chức năng Generate CSRF PoC trên Burp Suite (Trang 75)
Hình 3.9 Tạo file html với nội dung sau khi Generate CSRF PoC - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
Hình 3.9 Tạo file html với nội dung sau khi Generate CSRF PoC (Trang 76)
Tiếp theo ta được màn hình như bên dưới. - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
i ếp theo ta được màn hình như bên dưới (Trang 81)
Cấu hình và sử dụng thành phần Proxy của Burp Suite - BỘ BÀI HƯỚNG DẪN THỰC HÀNH KHAI THÁC LỖ HỔNG ỨNG DỤNGWEB TRÊN BWAPP
u hình và sử dụng thành phần Proxy của Burp Suite (Trang 82)

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w