2.1.1. SQL injection
a. Khái niệm
Đây là lỗ hổng có ảnh hƣởng trực tiếp tới cơ sở dữ liệu của website. Đây không chỉ là khuyết điểm của riêng SQL Server mà nó còn là vấn đề chung cho toàn bộ các cơ sở dữ liệu khác nhƣ Oracle, MS Access hay IBM DB2.
Khi hacker gửi những dữ liệu (thông qua các form), ứng dụng Web sẽ thực hiện và trả về cho trình duyệt kết quả câu truy vấn hay những thông báo lỗi có liên quan đến cơ sở dữ liệu. Và nhờ những thông tin này mà hacker biết đƣợc nội dung cơ sở dữ liệu và từ đó có thể điều khiển toàn bộ hệ thống ứng dụng.
b. Nguyên nhân lỗi
SQL injection là lỗi trong quá trình lập trình Web về phần truy xuất cơ sở dữ liệu của lập trình viên.
- Lập trình viên vẫn thƣờng mắc những lỗi cơ bản khi áp dụng vào ứng dụng web do không hiểu rõ hết các đặc điểm mã hóa. Những lỗi thông thƣờng bao gồm: không mã hóa dữ liệu quan trọng nhƣ khóa, certificates và mật khẩu, lƣu trữ các khóa bảo mật trong bộ nhớ bằng các cơ chế không an toàn, cơ chế tạo số ngẫu nhiên không đảm bảo, sử dụng sai thuật toán...
- Dữ liệu do ngƣời dùng nhập vào đƣợc sử dụng trực tiếp làm thành phần của câu truy vấn mà không qua bƣớc kiểm tra
c. Giải pháp và cách phòng chánh
Trong hầu hết trình duyệt, những kí tự nên đƣợc mã hoá trên địa chỉ URL trƣớc khi đƣợc sử dụng.
- Việc tấn công theo SQL Injection dựa vào những câu thông báo lỗi do đó việc phòng chống hay nhất vẫn là không cho hiển thị những thông điệp lỗi cho ngƣời dùng bằng cách thay thế những lỗi thông báo bằng 1 trang do ngƣời phát triển thiết kế mỗi khi lỗi xảy ra trên ứng dụng.
- Kiểm tra kĩ giá trị nhập vào của ngƣời dùng, thay thế những kí tự nhƣ „ ; v..v..
- Hãy loại bỏ các kí tự meta nhƣ “',",/,\,;“ và các kí tự extend nhƣ NULL, CR, LF, ... trong các string nhận đƣợc từ:
o Dữ liệu nhập do ngƣời dùng đệ trình o Các tham số từ URL
31 o Các giá trị từ cookie
Đối với các giá trị numeric, hãy chuyển nó sang integer trƣớc khi thực hiện câu truy vấn SQL, hoặc dùng ISNUMERIC để chắc chắn nó là một số integer.
Dùng thuật toán để mã hoá dữ liệu
2.1.2. XSS
a. Khái niệm
XSS là một lỗ hổng có thể phát sinh ở các phần của một website, nơi mà ngƣời dùng có thể nhập dữ liệu vào và sau đó nhận đƣợc một cái gì đó. Chủ yếu XSS nằm ở phần: search, error message, web form
Đây là một lỗ hổng phổ biến, có rất nhiều trang web bị mắc phải lỗi này, chính vì thế lỗ hổng này ngày càng đƣợc nhiều ngƣời quan tâm.
b. Nguyên nhân gây lỗi
- Ngƣời thiết kế ứng dụng web không kiểm tra kỹ dữ liệu do ngƣời dùng nhập vào
- Các biến không đƣợc ngƣời lập trình xử lý trƣớc khi hiện ra trình duyệt
c. Giải pháp và cách phòng chánh
- Với những dữ liệu, thông tin nhập của ngƣời dùng, ngƣời thiết kế ứng dụng Web cần phải thực hiện vài bƣớc cơ bản sau:
- Tạo ra danh sách những thẻ HTML đƣợc phép sử dụng.
- Xóa bỏ thẻ <script>
- Lọc ra bất kì một đoạn mã JavaScript/Java/VBScript/ActiveX/Flash Related nào.
- Lọc dấu nháy đơn hay kép.
- Lọc kí tự Null ( vì khả năng thêm một đoạn mã bất kì sau kí tự Null khiến cho ứng dụng dù đã lọc bỏ Script vẫn không nhận ra do ứng dụng nghĩ rằng chuỗi đã kết thức từ kí tự Null này. (adsbygoogle = window.adsbygoogle || []).push({});
- Đối với ngƣời dùng, cần cấu hình lại trình duyệt để nhắc nhở ngƣời dùng có cho thực thi ngôn ngữ kịch bản trên máy của họ hay không? Tùy vào mức độ thực thi nguồn tin mà ngƣời dùng sẽ quyết định.
- Lỗi XSS có thể tránh đƣợc khi máy chủ Web đảm bảo những trang phát sinh đƣợc mã hoá thích hợp. Tuy nhiên việc mã hoá tất cả dữ liệu không đáng tin cậy có thể tốn tài nguyên và ảnh hƣởng đến khả năng thực thi của một số máy chủ
2.1.3. CSRF
a. Khái niệm
Lỗ hổng CSRF lừa ngƣời sử dụng truy cập vào đƣờng link chứa mã độc để ăn cắp thông tin hoặc chiếm quyền kiểm soát. Bằng cách lừa cho ngƣời dùng thực hiện một số hành động mà họ không mong muốn lên ứng dụng web bằng chính quyền của ngƣời dùng đó. Sử dụng một số thủ thuật đơn giản nhƣ gửi link qua email, chat, kẻ tấn công
32
có thể lừa ngƣời dùng thực hiện một số tác vụ lên ứng dụng bị lỗi CSRF nhƣ xóa bài, thêm ngƣời dùng, thay đổi email, thay đổi mật khẩu của nạn nhân
b. Nguyên nhân lỗi
Nguyên nhân dẫn tới lỗi này là do lập trình viên không tuân thủ các quy tắc bảo vệ CSRF khi thiết kế và sử dụng câu lệnh trên cơ sở dữ liệu. Ngoài ra việc sử dụng phƣơng thức Post trong các form hoặc thực thi đầu cuối cũng là nguyên nhân gây ra lỗ hổng này
c. Cách phòng tránh
Dựa trên nguyên tắc của CSRF là “lừa trình duyệt của ngƣời dùng (hoặc ngƣời dùng) gửi các câu lệnh HTTP”, các kỹ thuật phòng tránh sẽ tập trung vào việc tìm cách phân biệt, hạn chế các câu lệnh giả mạo. Có nhiều lời khuyến cáo đƣợc đƣa ra, tuy nhiên cho đến nay vẫn chƣa có biện pháp nào có thể phòng chống triệt để CSRF. Sau đây là một số kỹ thuật đƣợc sử dụng.
- Trang web gây ra những thay đổi về trạng thái nhƣ chèn cơ sở dữ liệu, sử dụng các thông báo xác nhận.
Theo báo cáo thì nhiều ngƣời nghĩ rằng việc yêu cầu xác nhận cho những hành động của ngƣời dùng cung cấp khả năng bảo vệ, chống lại đƣợc CSRF
- Sử dụng POST.
Mọi kịch bản của tệp… đòi hỏi sử dụng HTTP POST. Điều này là do bản chất nền tảng của web. Các trang sử dụng phƣơng thức GET thì các thông số có thể đƣợc đánh dấu, lƣu trữ và di chuyển. Vì vậy các yêu cầu GET bị gửi các kịch bản làm thay đổi dữ liệu là điều không mong muốn. Do đó các form có ảnh hƣởng nhƣ vậy nên dùng phƣơng thức POST và các thực thi đầu-cuối nên tìm các tham số POST. Bên cạnh hiệu quả này thì nó còn giúp chống lại các yêu cầu nhúng ảnh trong các cuộc tấn công CSRF. Tuy nhiên có rất nhiều trang web trên internet với các lỗ hổng XSS vì vậy kẻ tấn công có thể dễ dàng tìm thấy một trang web từ đó khởi động một cuộc tấn công dựa trên POST. Điều này không phải nói rằng các ứng dụng web không nên sử dụng phƣơng thức POST nhƣng nó cũng không có nghĩa là đảm bảo an toàn.
- Sử dụng Captcha.
Captcha đƣợc dùng để ngăn chặn các kịch bản tự động từ các form đệ trình trên trang web. Đó là một quá trình một máy tính yêu cầu một ngƣời dùng hoàn tất một kiểm tra đơn giản mà máy tính có thể dễ dàng tạo ra và đánh giá nhƣng không thể tự nó giải quyết đƣợc. Chúng thƣờng đƣa ra hình ảnh méo mó của những văn bản và yêu cầu ngƣời dùng nhập lại. Vì máy tính không thể tự giải
33
quyết Captcha nên bất kỳ ngƣời dùng nào nhập vào lời giải đúng sẽ đƣợc xem là con ngƣời.
- Sử dụng cookie riêng biệt cho phần quản trị.
- Thiết kế hệ thống log: một vài framework ghi tất cả các thông tin, dữ liệu xử lý vào các file log. Điều này là rất nguy hiểm nếu nhƣ đó là các thông tin nhạy cảm nhƣ mật khẩu, số tài khoản…
2.1.4. Tràn bộ đệm
a. Khái niệm
Lỗi tràn bộ nhớ đệm hay gọi tắt là lỗi tràn bộ đệm là một lỗi lập trình có thể gây ra một ngoại lệ truy nhập bộ nhớ máy tính và chƣơng trình bị kết thúc, hoặc khi ngƣời dùng có ý phá hoại, họ có thể lợi dụng lỗi này để phá vỡ an ninh hệ thống
b. Nguyên nhân lỗi
Phát sinh từ khả năng lập trình yếu kém của những nhà lập trình. Đơn cử là sự cẩu thả trong kiểm tra kích thƣớc dữ liệu nhập vào.
c. Cách phòng chánh
- Ngƣời thiết kế Web cần phải kiểm tra kĩ kích thƣớc dữ liệu trƣớc khi sử dụng.
- Dùng Referer trong HTTP Header để kiểm tra yêu cầu có phải xuất phát từ máy ngƣời dùng
2.2. Nghiên cứu các kỹ thuật phân tích lỗ hổng cổng thông tin điện tử 2.2.1. Kỹ thuật phân tích tĩnh 2.2.1. Kỹ thuật phân tích tĩnh (adsbygoogle = window.adsbygoogle || []).push({});
Phân tích tĩnh là quá trình phân tích mã nguồn câu lệnh truy vấn SQL đƣợc tạo ra từ đầu vào ngƣời dùng mà không cần thực thi chƣơng trình. Công việc này sẽ giúp lập trình viên hiểu biết tốt hơn về mã nguồn ứng dụng, kiểm soát đƣợc luồng dữ liệu, đồng thời phát hiện và xác định đƣợc các lỗ hổng SQL Injection có thể tiềm ẩn trong ứng dụng
Kỹ thuậtphân tích tĩnhphát hiện lỗ hổng XSS
Kỹ thuật này không chỉ phát hiện các lỗ hổng XSS do không kiểm soát đƣợc các dữ liệu không đáng tin cậy mà còn phát hiện đƣợc cả các lỗ hổng XSS do không có đủ dữ liệu đáng tín cậy để kiểm tra
Kỹ thuật này bao gồm 2 phần
Phần 1: Phân tích chuỗi thích hợp để theo dõi các chuỗi con không đáng tin cậy Phần 2: Kiểm tra các script không đáng tin cậy sử dụng kỹ thuật ngôn ngữ hình thức[1]
2.2.2. Kỹ thuật phân tích động
Kỹ thuật phân tích động là phƣơng pháp phân tích các thông tin nhận đƣợc trong quá trình thực thi ứng dụng để phát hiện các lỗ hổng. Các thông tin này có thể bao gồm: Các phản hồi nhận đƣợc từ ứng dụng Web, các thông báo lỗi…Phân tích động có
34
thể đƣợc thực hiện tại thời điểm kiểm thử ứng dụng trong quá trình phát triển xây dựng, hoặc thời điểm sau khi ứng dụng đƣợc phát hành[2]
Mục tiêu của kỹ thuật này là để phát hiện ra các lỗ hổng bảo mật trong chƣơng trình khi nó đang thực hiện các truy vấn bất hợp pháp/ truy vấn logic sai, truy vấn UNION, truy vấn bổ sung. [7]
Phƣơng pháp phân tích động có lợi thế hơn phƣơng pháp phân tích tĩnh vì không phải lúc nào mã nguồn của ứng dụng web cũng đƣợc công bố. Tuy nhiên, những lỗ hổng này phải đƣợc vá hay sữa chữa bởi các lập trình viên, mà không phải tất cả các lập trình viên đều có thể sử dụng phƣơng pháp này để tìm kiếm lỗ hổng trên ứng dụng web của họ
Tiếp cận dựa trên phỏng đoán
Giới thiệu
Kỹ thuật tiếp cận dựa trên phỏng đoán là một kỹ thuật dựa trên cơ sở tri thức heuristics. Cụ thể trong phƣơng pháp này, đầu tiên sẽ phân tích ứng dụng web với mục đích xác định các hình thức đầu vào của nó. Sau đó, nó gieo một loạt các cuộc tấn công SQL chuẩn với mục tiêu cho phép các ứng dụng web gửi ra thông báo lỗi. Cuộc tấn công chuẩn sẽ bao gồm một tập hợp các chuỗi truy vấn mà không phụ thuộc vào các ứng dụng web. Sau đó, nó so sánh các thông báo trả về của ứng dụng web với một thƣ viện chuẩn chứa các thông báo lỗi liên quan mà cơ sở dữ liệu có thể trả về. Từ đó, tiếp tục tấn công sử dụng các thông báo lỗi, cho tới khi xác định đƣợc tên trƣờng, bảng hoặc cấu trúc cơ sở dữ liệu .
Phƣơng pháp tiếp cận
Kỹ thuật tiếp cận này bao gồm 4 bƣớc
Bƣớc 1: Phục hồi cấu trúc ứng dụng Web
Giai đoạn này nhằm mục đích thu thập thông tin về cấu trúc của các ứng dụng Web cần kiểm tra, bao gồm các trang và siêu liên kết có thể kết nối tới một trang khác. Về cơ bản, trong giai đoạn này công cụ hoạt động nhƣ một trình thu thập web, bằng cách điều hƣớng và tải trang web (tĩnh hoặc động) dựa trên các siêu liên kết.
Bƣớc 2: Xác định các Đầu vào ứng dụng web cũng đƣợc gọi là "điểm nóng"
Giai đoạn này sẽ dựa trên cấu trúc website xây dựng đƣợc từ bƣớc 1, để xác định các thông số đầu vào trong các form HTML. Đây chính là điểm khởi đầu cho các cuộc tấn công ở bƣớc 3.
Bƣớc 3:Thực hiện các cuộc tấn công
Trên cơ sở các thông số dễ bị tổn thƣơng, công cụ đƣợc sử dụng trong kỹ thuật (V1p3R)bắt đầu tiêm chuỗi SQL trong đầu vào, sử dụng một bộ biến heuristic có sẵn trong cơ sở tri thức của mình. Chi tiết sẽ đƣợc trình bày trong phần sau
35
V1p3R sẽ tạo ra tập file log, nơi mà tất cả các bƣớc của cuộc tấn công đƣợc ghi nhận. Giai đoạn này sẽ theo dõi tất cả các thông tin về các cuộc tấn công thành công, cũng nhƣ các trang, tham số, HTTP header dễ bị tổn thƣơng. Giai đoạn này cũng sinh ra các tri thức mới dựa trên các kết quả đầu ra chính xác hoặc không chính xác của ứng dụng web và sẽ đƣợc sử dụng để tạo ra dữ liệu thử nghiệm mới, nghĩa là lặp đi lặp lại cách tiếp cận thông qua Bƣớc III cho đến khi nó kết thúc danh sách các thông số đƣợc liệt kê.
Khai thác thông tin từ các message lỗi
Có rất nhiều kiểu message lỗi có thể trả ra nếu một trang web bị lỗi, mà từ đó có thể thực hiện các cuộc tấn công
Ví dụ:
Hình 2.1:Một thông báo lỗi đƣợc trả về liên quan tới hệ quản trị CSDL
Các thông báo này cung cấp thông tin về các hệ quản trị CSDL (Microsoft SQL Server)và dữ liệu truy cập (ODBC). Nó cũng cung cấp thông tin về phƣơng ngữ SQL đƣợc sử dụng, (Transact-SQL trong ví dụ này).
Phía dƣới là một lỗi xảy ra cho thấy các truy vấn gửi đến cơ sở dữ liệu đã đƣợc xây dựng bằng cách soạn các chuỗi đƣợc định nghĩa trong mã nguồn với các giá trị của các đầu vào mà không đƣợc thực hiện lọc (adsbygoogle = window.adsbygoogle || []).push({});
Loại thông báo lỗi thứ 2 liên quan tới cấu trúc của cơ sở dữ liệu, và giúp phát hiện ra kiểu, tên của các trƣờng trong các bảng
Ví dụ thông báo lỗi sau:
36
Thông báo này cho biết trong CSDL có một bảng có tên là “user”, trong bảng này có một trƣờng là “id”. Từ đây có thể tiếp tục tấn công để khai thác thông tin về CSDL của webiste này.
Nói chung, V1p3R cố gắng so khớp các thông báo lỗi xuất ra bởi hệ thống với một thƣ viện các biểu thức thông thƣờng, đƣợc xác định cho 15 mẫu lỗi sản xuất bởi 5 DBMS khác nhau.
Rõ ràng, một thƣ viện nhƣ vậy có thể dễ dàng mở rộng thêm nhiều mẫu nữa. Khi kết hợp các mẫu, nhƣ thể hiện trong ví dụ trên, dựa vào các thông tin mà ứng dụng web trả ra, nó có thể sử dụng để tiếp tục tấn công.
Khai thác thông tin từ các đầu ra hợp lệ
Nếu một trang web không xuất ra các thông báo lỗi, V1p3R có thể thu thập thông tin về cấu trúc của cơ sở dữ liệu bằng cách áp dụng kỹ thuật gọi là SQL injection suy luận(inferential SQL injection). Kỹ thuật này chỉ gồm việc sẽ có đƣợc một trả lời đúng hay sai khi tiêm(injection), từ đó có thể khai thác đƣợc thông tin CSDL
Sau đây, là chi tiết về kiến trúc của công cụ hỗ trợ trong kỹ thuật này V1p3R
Hình 2.3: Kiến trúc V1p3R
Công cụ này đƣợc phát triển bằng ngôn ngữ Perl, một ngôn ngữ khá phổ biến
Đầu tiên “Crawler” sẽ thu thập thông tin và dựng lại cấu trúc trang web(bƣớc 1). Sau đó các điểm nóng sẽ đƣợc xác định (bƣớc 2). Từ đó “injector ” sẽ thực hiện gửi các yêu cầu tới ứng dụng web sử dụng các SQL string library(bƣớc 3). Cuối cùng các thông báo lỗi trả ra từ ứng dụng web sẽ đƣợc so sánh với Error patterns libraray. Nếu
37
lỗi đƣợc xác định của DBMS nào thì V1p3R sẽ thực hiện tiêm các câu lệnh đặc biệt