Trong quá trình làm việc ở vị trí Công nhân vận hành Burp Suite, mình đã từng làm qua hơn trăm dự án khác nhau, tham gia các chương trình bug bounty, tìm lỗ hổng dạo khi lướt web linh tinh,... Đối tượng chính mình thực hiện tìm lỗ hổng bảo mật là các Web App, thuộc nhiều loại như: quản lý tổ chức, thương mại điện tử, diễn đàn, mạng xã hội, mua bán nội dung số, hẹn hò, nhắn tin,...

Số lượng lỗ hổng bảo mật mình tìm được cũng kha khá, và các loại lỗ hổng gặp được cũng đa dạng. Nhưng mỗi khi kết thúc quá trình tìm kiếm lỗ hổng trong một Web App kết thúc, trong đầu mình luôn có những băn khoăn: mình đã tìm hết tất cả những lỗi có thể chưa? đã test đầy đủ các chức năng chưa? liệu có còn sót lỗi nào quên chưa thử không?

Tất nhiên là có rồi 🤡

Việc tìm sót lỗi, không tìm không ra lỗi hoàn toàn có thể xảy ra. Nhìn thấy mình và người khác cùng kiểm tra một chức năng, mà người ta tìm ra lỗ hổng bảo mật, còn mình thì chỉ tìm thấy...

Tìm sót lỗi: lỗ hổng bảo mật có thể tìm ra được, nhưng do sơ ý, không cẩn thận nên đã bỏ qua, không tìm thấy. Khác với những lỗ hổng không tìm thấy do năng lực yếu kém, không đủ.

Tổng kết lại những lần mà tìm sót lỗi, còn đồng nghiệp thì lại tìm ra, mình nhận thấy đa số lỗi bị sót là những lỗi thuộc dạng "low hanging fruits". Và trong bài viết này, mình muốn giới thiệu với mọi người rổ trái cây mà mình đã từng làm rơi.

1. Un-auth access

Nguyên nhân

Đây là lỗ hổng mình từng bị sót rất nhiều, một phần do chủ quan không kiểm tra:

• Chủ quan chỉ kiểm tra API: khi thực hiện kiểm thử các Web App tương tác với Server qua API, mình thường tập trung kiểm tra đối với API nhiều hơn. Vì mình thường thấy front-end chủ yếu sẽ chỉ nhận dữ liệu từ Server qua API, sau đó xử lý và hiển thị cho người dùng. Những lần mình bị sót là do có một số trang sẽ trả về dữ liệu nhạy cảm ngay trong HTML, mà trang đó lại có thể truy cập un-auth.
• Chủ quan chỉ kiểm tra với các API trả về dữ liệu quan trọng, dữ liệu nhạy cảm: thời điểm đó mình thường kiểm tra un-auth thủ công. Đối với những API quan trọng thì mình sẽ đưa vào Burp Repeater để gửi payload. Với test un-auth thì mình chỉ cần xoá hết Cookie, Session, header Authorization, Token,... và gửi request một lần để xác minh.
  Như vậy, những API mình không cảm thấy quan trọng có thể sẽ bị sót lỗi un-auth. Có thể tại thời điểm thực hiện pentest, API đó chưa trả về dữ liệu gì quan trọng, việc bỏ sót chưa xảy ra hậu quả gì. Nhưng nếu sau này API đó trả về dữ liệu nhạy cảm, thì việc sót lỗi lúc trước đã tạo ra 1 lỗ hổng bảo mật.

Một nguyên nhân nữa dẫn đến việc sót lỗi un-auth là do phương pháp kiểm tra thủ công. Việc mình kiểm tra thủ công sẽ không đảm bảo 100% lần nào cũng kiểm tra un-auth được. Sai sót hoàn toàn có thể xảy ra:

• Do tưởng bản thân đã kiểm tra rồi, nên không kiểm tra nữa.
• Do quá tập trung vào việc kiểm tra các lỗ hổng nghiêm trọng phổ biến như SQL injection, XSS, XXE,... Khi xác định các lỗ hổng này không tồn tại, hoặc không bypass được thì mình có thể quên kiểm tra trường hợp un-auth.

Cách khắc phục

Để tránh việc sót lỗ hổng un-auth, mình đã thực hiện những cách sau:

• Luôn dành ra thời gian để kiểm tra lại checklist lỗ hổng một cách cẩn thận.
• Kiểm tra lần lượt theo checklist lỗ hổng với mỗi API, mỗi url. Sau khi hoàn thành mới chuyển sang API/url khác.
• Tạo checklist tất cả các API và url để theo dõi, đảm bảo không kiểm tra thiếu API/url.
• Sử dụng Extension của Burp để hỗ trợ tự động kiểm tra un-auth, VD như extention Autorize.

2. Clickjacking

Nguyên nhân

Clickjacking không hẳn một lỗ hổng mình từng bỏ sót khi pentest, nói đúng thì đây là lỗ hổng mình từng không nghĩ đến việc kiểm tra nó luôn. Đã có giai đoạn mà trong đầu mình không nhớ đến có Clickjacking tồn tại.

Và hậu quả thì tất nhiên là sót lỗi Clickjacking với tỉ lệ bỏ sót là 100%

Mức độ nguy hiểm và hậu quả Clickjacking có thể gây ra thì có thể thay đổi tuỳ vào các trường hợp, nhưng đây vẫn là một lỗ hổng nguy hiểm. Ví dụ như lỗ hổng Clickjacking khi tồn tại ở một trang web không có nhiều chức năng quan trọng như trang web cho phép sinh ngẫu nhiên avatar vuông, thì việc khai thác Clickjacking không nguy hiểm. Nhưng nếu xuất hiện ở một trang web liên quan đến tiền như ngân hàng online, giao dịch chứng khoán, mua bán,... thì có thể gây ra thiệt hại về tài chính cho người dùng, ảnh hưởng xấu đến uy tín và danh tiếng của doanh nghiệp.

Cách khắc phục

Sau khi nhận ra lỗi lầm, mình đã phải thực hiện ngay các biện pháp để không bỏ sót Clickjacking lần nào nữa:

• Bổ sung Clickjacking vào checklist lỗ hổng cần kiểm tra.
• Để ý các thông báo từ Burp scan, để ý header của Web App.
• Sử dụng các công cụ kiểm tra Clickjacking như https://clickjacker.io/ hoặc có thể tự viết một trang HTML để kiểm tra.