Loading...

2019-02-17

Home » » Các lỗi bảo mật cơ bản mà các developer hay gặp

Các lỗi bảo mật cơ bản mà các developer hay gặp

20:27:00    

Các lỗi bảo mật cơ bản mà các developer hay gặp


Mở bài

Chào các thành viên Kipalog :D
Mình không biết viết văn, nên câu chữ lủng củng, mong mọi người hiểu được =))
Mục đích bài viết này là chia sẻ đến các Developer (Dev), đặc biệt là các bạn Dev ít kinh nghiệm về vấn để bảo mật cho ứng dụng web.
Kiến thức mình có hạn, nên không nói sâu được, nên mình xin được chia sẻ những kiến thức mình có về các lỗi cơ bản mà rất hay gặp mà các Dev gần như sẽ gặp trong kiếp Coder của mình :D
Mình sẽ không giải thích dài dòng, các bạn chủ động hỏi thằng bạn thân Google để tìm hiểu thêm

Lan man xíu

Điều gì ở ứng viên mà mình quan tâm nhất?
Mình thỉnh thoảng có phụ trách tuyển dụng PHP cho nhóm Sản phẩm của công ty. Yếu tố quan trọng nhất cho một ứng viên PHP với mình là gì. Tất nhiên del phải là bảo mật mà là trung thực và chịu khó =)). Nhưng tư duy và tư duy bảo mật là số 2, kiến thức thì học sau
Các điểm chung của các lỗi bảo mật này là gì?
Mình cho là mình tin tưởng về các Input mà client gửi lên (cứ nghĩ input đó là ok rồi). Nên chốt là del bao giờ tin những gì thằng Client gửi lên hết => Phải xử lý input client gửi lên trước khi xử lý việc khác

Thân bài

Các lỗi bảo mật dễ mắc phải

Mình xếp theo mức độ nguy hiểm giảm dần, theo quan điểm cá nhân mình xD

1, SQL Injection

Không phải nói nhiều về cái lỗi thần thánh này, gần như Dev mới 96.69 đều mắc phải nó -_- thậm chí các Dev có kinh nghiệm cũng có thể mắc :D
Lấy ví dụ phần login cho một website nha
- Lỗi xảy ra như thế nào
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à quydo, mật khẩu là matkhauManhVL
Nhưng vấn đề là nhiều thanh niên không thích thế, ví dụ nhập username là quydo' or 1-- - và mật khẩu là nhập linh ta linh tinh đi kadslfjladsjfkldsfjladskfjaskldfjadsklf
Khi đó query mà bạn đang chờ sẽ là
$sql = "select * from users where username='quydo' or 1 limit 1-- - and password='kadslfjladsjfkldsfjladskfjaskldfjadsklf'
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, XSS

Lấy ví dụ phần search cho một website nha
- Lỗi xảy ra như thế nào
Giả sử url trang search là
http://domain.com/search.php?keyword=user_keyword
Và trong trang search.php, và ở trang search.php bạn có dòng
echo "Kết quả tìm kiếm cho từ khóa: ".$_GET['keyword'];
Nếu người dùng nhập keyword bình thường ví dụ: xem phim xxx, maria ozawa gì đó thì ok
Nhưng nếu người dùng thích nhập khác, ví dụ:
Thì lúc load trang search.php?keyword=
1 cái alert bằng javascript sẽ xuất hiện với nội dung "aloxo xss"
Thường thì các form input hay bị như thông tin tài khoản, phần bình luận comment :D
Mình cũng bị dính vụ comment lúc mới Dev, có thanh niên làm cái insert 10k có cái alert javascript vào -_-

3, Upload

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... Có 1 bug mà rất nguy hiểm, dựa vào hàm moveuploaded_file để upload php backdoor lên

link đây http://www.paulosyibelo.com/2015/03/exploiting-php-upload-forms-with-cve.html

4, Insecure Direct Object References

Cái này cũng khá hay gặp, nhất là ở phần API, bạn xem tham khảo của #toidicodedao link mình gửi trên đó, có phần này, rất hay và chi tiết. Hoặc bài của anh Juno_okyo về trang web CGV film đó :D
Hoặc ví dụ mà cái anh gì bên VNsecurity ví dụ về site bán vé online lớn nhất VN tickets gì đó ở Trà đá hacking lần 2
Ví dụ ở cái app đi, sẽ có 1 API /user/transaction/Trans_id để lấy info giao dịch của người dùng
user gọi api, api get thông tin giao dịch có id=Trans_id để trả lại cho user, ok :D
Lỗi ở đây là Dev không kiểm tra cái Trans_id có thuộc về user đó không
Nên có thể thay Trans_id khác, mà API vẫn trả về :D

5, Remote Code Execution

Để chạy được cái này khá nhiều điều kiện, bạn có thể search Google để biết thêm chi tiết

6. Remote file inclusion

Giờ cái này khá hiếm, nếu mà được thì nguy hiểm, khi file include là con backdoor shell
Các lỗi mà bạn không hiểu thì chịu khó Google để tìm hiểu nha. 4 cái đầu là nguy hiểm nhất nên mình có ví dụ cơ bản :D
Mọi người có ý kiến đóng góp gì thì comment để mình fix lại
Văn vẻ lủng củng mọi người thông cảm =))