Các lỗi bảo mật website thường gặp nhất

1. Lỗ hổng SQL Injection

SQL Injection là một trong những lỗ hổng bảo mật phổ biến nhất, nó thường được sử dụng để khai thác lỗ hổng của trang web trên nền tảng PHP hoặc ASP. Các cuộc tấn công bao gồm việc tiêm mã độc vào những truy vấn SQL trong ứng dụng của bạn thông qua các giá trị đầu vào của ứng dụng. Nếu thành công sẽ cho phép kẻ tấn công thêm hoặc xóa nội dung cơ sở dữ liệu, lấy các giá trị trong CSDL như email, mật khẩu hoặc thông tin cá nhân người dùng trang web. SQL Injection có thể xảy ra nếu một trang web chấp nhận những truy vấn không đáng tin cậy vào cơ sở dữ liệu hoặc tạo ra chúng một cách tự động.

Giả sử rằng các biến đăng nhập (bao gồm tên và mật khẩu) được đưa trực tiếp đến các câu truy vấn SQL thông qua phương thức POST. Một đoạn code sẽ chịu trách nhiệm xử lý việc đăng nhập của người dùng có thể dễ dàng bị tổn thương:

Câu query bạn mong muốn sẽ là

$sql = "SELECT * FROM users WHERE username='".$_POST['username']."' and password='".$_POST['password']."'"; // :D

Còn gì tuyệt vời hơn nếu người dùng nhập, ví dụ username là code24h, mật khẩu là matkhaulinhtinh

Nhưng vấn đề là nhiều thanh niên không thích thế, ví dụ nhập username là code24h' or 1-- - và mật khẩu là nhập bất kỳ cccvv12cv
Khi đó query mà bạn đang chờ sẽ là

$sql = "select * from users where username='code24h' or 1 limit 1-- - and password='cccvv12cv'

Câu query luôn đúng bởi -- - là dùng để kết thúc 1 câu query, như // trong php đó

- Sự nguy hiểm
user chạy ở đây là user connect tới database server (không phải user của web server)

• Thứ nhất là có thể truy xuất gần như là toàn bộ thông tin về cơ sở dữ liệu đang thao thác
  và có thể các database (do grant quyền)

• Thứ hai là có thể query insert, update, drop đến database hiện tại :D ví dụ có thanh niên chạy drop database database_name thì thôi xong (cái này phụ thuộc nhiều yếu tố mới thành công)

• Thứ 3 là có thể upload backdoor (cụ thể là php shell), phải phụ thuộc khá nhiều điều kiện
  user chạy là root (hoặc user có quyền với file), biết được cấu trúc website đang chạy (ví dụ biết được /var/www/domain.com), cái này mà được thì rất nguy hiểm

Thường thì các attacker sẽ tìm phần login admin => login vào admin backend, dựa vào các bug (chủ yếu là upload) để upload backdoor (php shell) lên :D.

2. Lỗ hổng Cross-Site Scripting

Cross-Site Scripting (XSS) là một trong những kĩ thuật tấn công phổ biến nhất hiên nay, đồng thời nó cũng là một trong những vấn đề bảo mật quan trọng đối với các nhà phát triển web và cả những người sử dụng web. Bất kì một website nào cho phép người sử dụng đăng thông tin mà không có sự kiểm tra chặt chẽ các đoạn mã nguy hiểm thì đều có thể tiềm ẩn các lỗi XSS.

Cross-Site Scripting hay còn được gọi tắt là XSS (thay vì gọi tắt là CSS để tránh nhầm lẫn với CSS-Cascading Style Sheet của HTML) là một kĩ thuật tấn công bằng cách chèn vào các website động (ASP, PHP, CGI, 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 nạn nhân sử dụng.

Phụ thuộc vào mục đích của hacker, những đoạn Javascript được chèn vào để lấy những thông tin như:

• Cookie: hacker có thể lấy được cookie của người dùng và dùng những thông tin trong cookie để giả mạo phiên truy cập hoặc lấy những thông tin nhạy cảm khác được lưu trong cookie.

• Keylogging: hacker có thể ghi lại những thao tác gõ phím của người dùng bằng cách sử dụng sự kiện trong Javascript và gửi tất cả những thao tác gõ phím đó về cho hắn để thực hiện những mục đích như đánh cắp các thông tin nhạy cảm, lấy mật khẩu truy cập website hoặc mã số thẻ tín dụng...

• Phishing: hacker có thể thay đổi giao diện của website bằng cách thay đổi cấu trúc HTML trong trang web để đánh lừa người dùng. Hacker có thể tạo ra những form đăng nhập giả nhằm lừa người dùng đăng nhập vào để đánh cắp mật khẩu.

Sau đó các thông tin này được gửi tới cho hacker . Cách thường dùng của hacker là mã hoá các phần nguy hiểm của link ( đã chèn code) thành kiểu HEX ( hoặc có thể là các hình thức khác ) để làm cho nạn nhân ít nghi ngờ khi click vào cái link nguy hiểm đó . Sau đó là tìm cách nào đó để cho nạn nhân chịu click vào cái link đó.

Hầu hết các ứng dụng web hiện nay dùng cookie để kết hợp 1 tài khoản duy nhất cho 1 người dùng nào đó , nghĩa là cookie của người nào người đó dùng . Các webmail , web bán hàng , nhà băng , ... đa số đều dùng cookie với mục đích chứng thực ngừơi dùng , và đây là cái mà hacker cần .

XSS hoạt động như thế nào?

Về cơ bản XSS cũng như SQL Injection hay Source Injection, nó cũng là các yêu cầu (request) được gửi từ các máy client tới server nhằm chèn vào đó các thông tin vượt quá tầm kiểm soát của server. Nó có thể là một request được gửi từ các form dữ liệu hoặc cũng có thể đó chỉ là các URL như là http://www.example.com/search.cgi?query=<script>alert('Website đang bị lỗi XSS!');</script>. Và rất có thể trình duyệt của bạn sẽ hiện lên một popup thông báo "Website đang bị lỗi XSS!".

3. Lỗi upload file

Lỗi xảy ra như thế nào

Dev không check kiểu file, hoặc chỉ check ở máy client
Ví dụ check kiểu file = javascript trước khi gửi lên là móm, có thể chỉnh sửa js nên bypass được
Code check không chính xác, có thể bypass được, ví dụ dùng cái này là móm ngay
if($FILES['file_field']['type'] == 'jpg') echo "tiếp tục";
Không thay đổi tên, lấy tên theo tên client gửi lên. Người dùng có thể cho tên file là shell.php.jpg, backdoor.php.rar... 

Trong một số trường hợp có những website cho sửa tên file và khi đó tên file sẽ được sửa thành shell.php, backdoor.php

Hacker hoàn toàn có thể chạy những file này và thực thi nhiều thứ.

4. Kỹ thuật tấn công CSRF 

CSRF là gì?

CSRF ( Cross Site Request Forgery) là kỹ thuật tấn công bằng cách sử dụng quyền chứng thực của người dùng đối với một website. CSRF là kỹ thuật tấn công vào người dùng, dựa vào đó hacker có thể thực thi những thao tác phải yêu cầu sự chứng thực. Hiểu một cách nôm na, đây là kỹ thuật tấn công dựa vào mượn quyền trái phép.

CSRF còn được gọi là "session riding", "XSRF"

Kịch bản tấn công CSRF

Các ứng dụng web hoạt động theo cơ chế nhận các câu lệnh HTTP từ người sử dụng, sau đó thực thi các câu lệnh này. Hacker sử dụng phương pháp CSRF để lừa trình duyệt của người dùng gửi đi các câu lệnh http đến các ứng dụng web. Điều đó có thể thực hiện bằng cách chèn mã độc hay link đến trang web mà người dùng đã được chứng thực. Trong trường hợp phiên làm việc của người dùng chưa hết hiệu lực thì các câu lệnh trên sẽ được thực hiện với quyền chứng thực của người sử dụng. Ta có thể xét ví dụ sau:

• Người dùng Alie truy cập 1 diễn đàn yêu thích của mình như thường lệ. Một người dùng khác, Bob đăng tải 1 thông điệp lên diễn đàn. Giả sử rằng Bob có ý đồ không tốt và anh ta muốn xóa đi một dự án quan trọng nào đó mà Alice đang làm.
• Bob sẽ tạo 1 bài viết, trong đó có chèn thêm 1 đoạn code như sau:

<img height="0" width="0" src="http://www.webapp.com/project/1/destroy">

Để tăng hiệu quả che dấu, đoạn mã trên có thể được thêm các thông điệp bình thường để người dùng không chú ý. Thêm vào đó thẻ img sử dụng trong trường hợp này có kích thước 0x0 pixel và người dùng sẽ không thể thấy được.

• Giả sử Alie đang truy cập vào tài khoản của mình ở www.webapp.com và chưa thực hiện logout để kết thúc. Bằng việc xem bài post, trình duyệt của Alice sẽ đọc thẻ img và cố gắng load ảnh từ www.webapp.com, do đó sẽ gửi câu lệnh xóa đến địa chỉ này.
• Ứng dụng web ở www.webapp.com sẽ chứng thực Alice và sẽ xóa project với ID là 1. Nó sẽ trả về trang kết quả mà không phải là ảnh, do đó trình duyệt sẽ không hiển thị ảnh.

Ngoài thẻ img, các thẻ html có thể sử dụng kĩ thuật trên có thể là:

<iframe height="0" width="0" src="http://www.webapp.com/project/1/destroy">

<link ref="stylesheet" href="http://www.webapp.com/project/1/destroy" type="text/css"/>

<bgsound src="http://www.webapp.com/project/1/destroy"/>

<background src="http://www.webapp.com/project/1/destroy"/>

<script type="text/javascript" src="http://www.webapp.com/project/1/destroy"/>

Các kĩ thuật CSRF rất đa dạng, lừa người dùng click vào link, gửi email chứa các đoạn mã độc đến người dùng… Hacker còn có thể che giấu các link ở trên rất khéo léo. Ví dụ trong trường hợp thẻ img, người dùng có thể nhận ra nếu vào đường link chứa trong

<ing src="http://www.webapp.com/project/1/destroy"/>

Tuy nhiên, người dùng sẽ rất có phát hiện nếu hacker dùng đường link như sau:

<img height="0" width="0" src="http://www.ahackersite.com/abc.jpg"/>

và cấu hình lại máy chủ:

Redirect 302/abc.jpg http://www.webapp.com/project/1/destroy"/>

Như vậy người dùng sẽ rất khó để có thể phát hiện, vấn đề trách nhiệm phần lớn thuộc về các website của các nhà cung cấp.

Để phòng tránh trở thành nạn nhân của các cuộc tấn công CSRF, người dùng internet nên thực hiện một số lưu ý sau:

• Nên thoát khỏi các website quan trọng: Tài khoản ngân hàng, thanh toán trực tuyến, các mạng xã hội, gmail, yahoo… khi đã thực hiện xong giao dịch hay các công việc cần làm. (Check - email, checkin…)
• Không nên click vào các đường dẫn mà bạn nhận được qua email, qua facebook … Khi bạn đưa chuột qua 1 đường dẫn, phía dưới bên trái của trình duyệt thường có địa chỉ website đích, bạn nên lưu ý để đến đúng trang mình muốn.
• Không lưu các thông tin về mật khẩu tại trình duyệt của mình (không nên chọn các phương thức "đăng nhập lần sau", "lưu mật khẩu" …
• Trong quá trình thực hiện giao dịch hay vào các website quan trọng không nên vào các website khác, có thể chứa các mã khai thác của kẻ tấn công.

 Phía server

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 vài kĩ thuật sử dụng.

Lựa chọn việc sử dụng GET VÀ POST

Sử dụng GET và POST đúng cách. Dùng GET nếu thao tác là truy vấn dữ liệu. Dùng POST nếu các thao tác tạo ra sự thay đổi hệ thống (theo khuyến cáo của W3C tổ chức tạo ra chuẩn http) Nếu ứng dụng của bạn theo chuẩn RESTful, bạn có thể dùng thêm các HTTP verbs, như PATCH, PUThay DELETE

 Sử dụng captcha, các thông báo xác nhận

Captcha được sử dụng để nhận biết đối tượng đang thao tác với hệ thống là con người hay không? Các thao tác quan trọng như "đăng nhập" hay là "chuyển khoản" ,"thanh toán" thường là hay sử dụng captcha. Tuy nhiên, việc sử dụng captcha có thể gây khó khăn cho một vài đối tượng người dùng và làm họ khó chịu. Các thông báo xác nhận cũng thường được sử dụng, ví dụ như việc hiển thị một thông báo xác nhận "bạn có muốn xóa hay k" cũng làm hạn chế các kĩ thuật Cả hai cách trên vẫn có thể bị vượt qua nếu kẻ tấn công có một kịch bản hoàn hảo và kết hợp với lỗi XSS.

 Sử dụng token

Tạo ra một token tương ứng với mỗi form, token này sẽ là duy nhất đối với mỗi form và thường thì hàm tạo ra token này sẽ nhận đối số là"SESSION" hoặc được lưu thông tin trong SESSION. Khi nhận lệnh HTTP POST về, hệ thống sẽ thực hiên so khớp giá trị token này để quyết định có thực hiện hay không. Mặc định trong Rails, khi tạo ứng dụng mới:

5. Lỗi dữ liệu đầu vào

Khi lấy dữ liệu của người dùng gửi lên, có thể qua phương thức GET, POST,....

Một số trường hợp bị lỗi như:

- Dữ liệu không có trong hệ thống, ví dụ như ID của bản ghi trong DB mà không kiểm trả thì không thể trả ra dữ liệu, và có thể xuất hiện nhiều sai lầm.

Ví dụ như link sau: http://code24h.com/seo-onpage-la-gi-d19396.htm

Cách thức này cũng khá phổ biến, nếu người dùng sửa ID từ 19396 thành 193996 thì khi lấy dữ liệu chưa có bản ghi theo ID mới này -> lỗi dữ liệu.

- Dữ liệu quá lớn bị tràn bộ nhớ. 

Cũng theo ví dụ trên, ID được thay bằng số vô cùng lớn sẽ dẫn đến lỗi này.

- Dữ liệu SQL, ví dụ như link sau

http://code24h.com/tim-kiem.htm?q=hoa

Người dùng sửa thành http://code24h.com/tim-kiem.htm?q=hoa'

Nếu không kiểm tra và có hướng sử lý cụ thể sẽ dẫn đến lỗi SQL

Trên đấy là một số vấn đề cơ bản dẫn đến lỗi cũng như bị ảnh hưởng đến an toàn hệ thống mình chia sẻ. Các bạn có nhứng vấn đề nào liên quan đến bảo mật website thì chia sẽ nhé.