GIAO THỨC HTTP “BẢO MẬT” ĐẾN MỨC NÀO?

HTTP là một giao thức dùng để truyền nhận dữ liệu. Nhược điểm của HTTP là dữ liệu được truyền dưới dạng plain text, không hề được mã hoá hay bảo mật. Điều này dẫn đến việc hacker có thể dễ dàng nghe lén, chôm chỉa và chỉnh sửa dữ liệu. Người ta gọi kiểu tấn công này là Man-in-the-middle attack, viết tắt là MITM.

Cách phòng chống

  • Dùng HTTPS + SSL Certificate
  • Sử dụng đăng nhập qua Google hoặc Facebook ở đây nó sẽ ko để lộ user và password, so với nếu dùng chỉ dùng http khẳ năng lộ user và password khi login sẽ rất cao. Nhưng vẫn có khả năng sẽ lộ cookie.

Lưu ý

  • Cần hết sức cẩn thận khi dùng wifi chùa/wifi công cộng vì hacker có thể dùng một số phần mềm như Fiddler đọc lén cookie cũng như thông tin nhạy cảm.

LỖ HỔNG BẢO MẬT XSS NGUY HIỂM ĐẾN MỨC NÀO?

XSS (Cross Site Scripting) là một lỗi bảo mật cho phép hacker nhúng mã độc (javascript) vào một trang web khác. Hacker có thể lợi dụng mã độc này để deface trang web, cài keylog, chiếm quyền điều khiển của người dùng, dụ dỗ người dùng tải virus về máy.

Những dạng XSS

  • 1. Persistent XSS

    • Kẻ tấn công chèn mã độc (thường là JavaScript) vào trang web, và mã này sẽ được lưu trữ lại trên data base của server.

    • Khi người dùng khác truy cập vào trang web và tải nội dung chứa mã độc, mã này sẽ được thực thi trên trình duyệt của họ.

    • Ví dụ

      • Trên ứng dụng nào đó, khi bạn post một comment vào topic, server sẽ lưu comment bạn post và hiển thị dưới dạng HTML.
      • import { Component } from "@angular/core";
@Component({
  selector: "app-comment",
  template: `
    <div *ngFor="let comment of comments">
      <div [innerHTML]="comment"></div>
    </div>
    <textarea
      [(ngModel)]="newComment"
      placeholder="Write a comment..."
    ></textarea>
    <button (click)="addComment()">Add Comment</button>
  `,
  styleUrls: ["./comment.component.css"],
})
export class CommentComponent {
  comments: string[] = [];
  newComment: string = "";

  addComment(): void {
    if (this.newComment.trim()) {
      this.comments.push(this.newComment); // Không có lọc hay xử lý ở đây
      this.newComment = ""; // Xóa nội dung comment sau khi thêm
    }
  }
}

          - Trường hợp newComment nếu nhập đầu vào là một mã độc vào bình luận
  ```typescript <script>alert('XSS!');</script>)``` Trình duyệt sẽ chạy đoạn script này, hiển thị cửa sổ alert lên. Hacker đã chèn được mã độc vào ứng dụng, thực hiện tấn công XSS thành công. Bất kì ai thấy comment này đều bị dính mã độc này, do đó kiểu tấn công này có tầm ảnh hưởng lớn, khá nguy hiểm.

  • 2. Reflected XSS

    • Với cách tấn công này, hacker chèn mã độc vào URL dưới dạng query string. Khi người dùng ngáo ngơ nhấp vào URL này, trang web sẽ đọc query string, render mã độc vào HTML và người dùng “dính bẫy”.

    • Ví dụ - Hacker gưi 1 đường link giả vào mail người dùng.Nội dung đường link: http://facebook.com?q=<script>deleteAccount();</script> . Khi các người dùng click link này, họ sẽ vào trang facebook. Sau đó server sẽ render <script>deleteAccount(); </script>, gọi hàm deleteAccount trong JavaScript để xoá account của họ. Tầm ảnh hưởng của ReflectedXSS không rộng bằng Persistance XSS, nhưng mức độ nguy hiểm là tương đương. Hacker thường gửi link có mã độc qua email, tin nhắn, … và dụ dỗ người dùng click vào. Do đó các bạn nên cẩn thận với những đường link ko đáng tin nhé.

Cách phòng tránh

  • 1. Encoding
    • Không được tin tưởng bất kì thứ gì người dùng nhập vào!! Hãy sử dụng hàm encode có sẵn trong ngôn ngữ/framework để chuyển các kí tự < > thành < %gt;.
  • 2. Validation/Sanitize - Validation: loại bỏ hoàn toàn các kí tự khả nghi trong input của người dùng, hoặc thông báo lỗi nếu trong input có các kí tự này. - Ngoài ra, nếu muốn cho phép người dùng nhập vào HTML, hãy sử dụng các thư viện sanitize. Các thư viện này sẽ lọc các thẻ HTML, CSS, JS nguy hiểm để chống XSS. Người dùng vẫn có thể sử dụng các thẻ <p>, , <ul> để trình bày văn bản. - Nếu bạn dùng framework Angular có thể sử dụng DomSanitizer - DomSanitizer: Dùng để đảm bảo rằng dữ liệu HTML đầu vào từ người dùng không chứa mã độc. - bypassSecurityTrustHtml: Chuyển đổi dữ liệu HTML đầu vào từ người dùng thành SafeHtml trước khi hiển thị, đảm bảo rằng nó không thể chứa các mã độc như JavaScript.
  • 3. CSP (Content Security Policy) - Ta có thể dùng chuẩn CSP để chống XSS. Với CSP, trình duyệt chỉ chạy JavaScript từ những domain được chỉ định. Giả sử thiendia.com có sử dụng CSP, chỉ chạy JavaScript có nguồn gốc thiendia.com. - Để sử dụng CSP, server chỉ cần thêm header Content-Security-Policy vào mỗi response. Nội dung header chứa những domain mà ta tin tưởng.

Cookie là một file text nhỏ được server gửi về client, sau đó browser lưu vào máy người dùng. Khi client gửi request tới server, nó sẽ gửi kèm cookie. Server dựa vào cookie này để nhận ra người dùng.

CSRF

Cookie có thể bị chôm theo các con đường sau:

  • Sniff cookie qua mạng: Sử dụng 1 số tool đơn giản để sniff như Fiddler, Wireshark, ta có thể chôm cookie của người dùng ở cùng mạng. Sau đó, sử dụng EditThisCookie để dump cookie này vào trình duyệt để mạo danh người dùng. (Xem demo phần HTTP).
  • Chôm cookie (Cookie thief) bằng XSS: Với lỗ hỗng XSS, hacker có thể chạy mã độc (JavaScript) ở phía người dùng. JS có thể đọc giá trị từ cookie với hàm document.cookie. Hacker có thể gửi cookie này tới server của mình. Cookie này sẽ được dùng để mạo danh người dùng. Thực hiện tấn công kiểu CSRF (Cross-site request forgery). Hacker có thể post một link ảnh như sau: 
    <img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">

    Trình duyệt sẽ tự động load link trong ảnh, dĩ nhiên là có kèm theo cookie. Đường link trong ảnh sẽ đọc cookie từ request, xác nhận người dùng, rút sạch tiền mà người dùng không hề hay biết. Cách tấn công này có rất nhiều biến thể, mình sẽ nói rõ ở phần sau.

Cách phòng tránh

  • Set Expired và Max-Age: Để giảm thiểu thiệt hại khi cookie bị trộm, ta không nên để cookie sống quá lâu. Nên set thời gian sống của cookie trong khoảng 1 ngày tới 3 tháng, tuỳ theo yêu cầu của application.
  • Sử dụng Flag HTTP Only: Cookie có flag này sẽ không thể truy cập thông qua hàm document.cookie. Do đó, dù web có bị lỗi XSS thì hacker không thể đánh cắp được nó.
  • Sử dụng Flag Secure: Cookie có flag này chỉ được gửi qua giao thức HTTPS, hacker sẽ không thể sniff được.

Lưu ý: Nếu website của bạn sử dụng RESTful API, đừng sử dụng cookie để authorize người dùng mà hãy dùng OAuth hoặc WebToken. Token này được vào Header của mỗi request nên sẽ không bị dính lỗi CSRF.

SQL INJECTION – LỖ HỔNG BẢO MẬT THẦN THÁNH

  • Đoạn code trên đọc thông tin nhập vào từ user và cộng chuỗi để thành câu lệnh SQL. Để thực hiện tấn công, Hacker có thể thay đổi thông tin nhập vào, từ đó thay đổi câu lệnh SQL.

  • Hacker có thể thông qua SQL Injection để dò tìm cấu trúc dữ liệu (Gồm những table nào, có những column gì), sau đó bắt đầu khai thác dữ liệu bằng cách sử dụng các câu lệnh như UNION, SELECT TOP 1…

Cách phòng chống

  • Lọc dữ liệu từ người dùng: Cách phòng chống này tương tự như XSS. Ta sử dụng filter để lọc các kí tự đặc biệt (; ” ‘) hoặc các từ khoá (SELECT, UNION) do người dùng nhập vào. Nên sử dụng thư viện/function được cung cấp bởi framework. Viết lại từ đầu vừa tốn thời gian vừa dễ sơ sót.

  • Không cộng chuỗi để tạo SQL: Sử dụng parameter thay vì cộng chuỗi. Nếu dữ liệu truyền vào không hợp pháp, SQL Engine sẽ tự động báo lỗi, ta không cần dùng code để check.

  • Không hiển thị exception, message lỗi: Hacker dựa vào message lỗi để tìm ra cấu trúc database. Khi có lỗi, ta chỉ hiện thông báo lỗi chứ đừng hiển thị đầy đủ thông tin về lỗi, tránh hacker lợi dụng.

  • Phân quyền rõ ràng trong DB: Nếu chỉ truy cập dữ liệu từ một số bảng, hãy tạo một account trong DB, gán quyền truy cập cho account đó chứ đừng dùng account root hay sa. Lúc này, dù hacker có inject được sql cũng không thể đọc dữ liệu từ các bảng chính, sửa hay xoá dữ liệu.

  • Backup dữ liệu thường xuyên: Các cụ có câu “cẩn tắc vô áy náy”. Dữ liệu phải thường xuyên được backup để nếu có bị hacker xoá thì ta vẫn có thể khôi phục được. Còn nếu cả dữ liệu backup cũng bị xoá luôn thì … chúc mừng bạn, update CV rồi tìm cách chuyển

Cross Site Request Forgery (CSRF) – NHỮNG CÚ LỪA NGOẠN MỤC

Ở bài trước, chúng ta biết rằng server sẽ lưu trữ cookie ở phía người dùng để phân biệt người dùng. Mỗi khi người dùng gửi một request tới một domain nào đó, cookie sẽ được gửi kèm theo.

CSRF

Cách phòng tránh

  • Sử dụng CSRF Token: Trong mỗi form hay request, ta đính kèm một CSRF token. Token này được tạo ra dựa theo session của user. Khi gửi về server, ta kiểm tra độ xác thực của session này. Do token này được tạo ngẫu nhiên dựa theo session nên hacker không thể làm giả được (Các framework như RoR, CodeIgniter, ASP.NET MVC đều hỗ trợ CSRF token).

  • Kiểm tra giá trị Referer và Origin trong header: Origin cho ta biết trang web gọi request này. Giá trị này được đính kèm trong mỗi request, hacker không chỉnh sửa được. Kiểm tra giá trị này, nếu nó là trang lạ thì không xử lý request.

  • Kiểm tra header X-Requested-With: Request chứa header này là request an toàn, vì header này ngăn không cho ta gửi request đến domain khác (chi tiết).

  • Cần cẩn thận đề phòng lỗi XSS: Với XSS, hacker có thể cài mã độc trên chính trang web cần tấn công. Lúc này, mọi phương pháp phòng chống CSRF như token, referrer đều bị vô hiệu hoá.

Tài liệu tham khảo