Cơ bản về bảo mật Web

Có rất nhiều nguyên do để học về bảo mật web như :

• Bạn lo lắng về việc để lộ thông tin cá nhân trên mạng.
• Bạn quan tâm đến tính bảo mật cho website hoặc ứng dụng của mình.
• Bạn là lập trình viên và đang đi xin việc, bạn muốn chuẩn bị sẵn cho trường hợp nhà tuyển dụng hỏi về các vấn đề bảo mật web.

… và nhiều nguyên do khác nữa .

Bài viết này sẽ giải thích một vài vấn đề bảo mật web thông dụng kèm theo thuật ngữ chuyên ngành của nó.

Bạn đang đọc: Cơ bản về bảo mật Web

Hai khái niệm cốt lõi trong bảo mật

– Không một ai hoàn toàn có thể bảo đảm an toàn 100 % .- Một lớp bảo vệ là không đủ .

Cross-Origin Resource Sharing (CORS)

Bạn đã khi nào gặp một thông tin lỗi dạng như này chưa ?

No 'Access-Control-Allow-Origin' header is present on the requested resource. 
Origin 'null' is therefore not allowed access.

Nếu đã gặp phải lỗi này, bạn sẽ thử tìm giải pháp trên Google. Và bạn sẽ thấy ai đó hướng dẫn cài 1 extension giúp cho lỗi này biến mất và website của bạn lại hoạt động giải trí thông thường .Nhưng liệu đây có phải cách làm tốt ?

CORS được sinh ra là để bảo vệ bạn chứ không phải để gây khó khăn cho bạn

Trước khi giải thích về CORS, chúng ta hãy cùng tìm hiểu lại về Cookies, đặc biệt là Authentication Cookies. Authentication Cookies được sử dụng để thông báo cho server biết rằng bạn đã đăng nhập vào hệ thống, và chúng được tự động gửi kèm mỗi request lên server.

Giả sử bạn đã đăng nhập vào Facebook, và họ sử dụng Authentication Cookies .Sau đó bạn click vào 1 link bất kể trên mạng, ví dụ link video full 9 phút và nó sẽ redirect bạn về 1 website nào đó của hacker. Website này sẽ tự động hóa chạy 1 đoạn code Javascript để thực thi request lên facebook.com có kèm theo authentication cookie của bạn !Trong một quốc tế không có CORS, hacker hoàn toàn có thể triển khai những thao tác trên Facebook với thông tin tài khoản của bạn mà bạn không hề hay biết. Ví dụ như đăng tin lên trên dòng thời hạn của bạn kèm theo link video full 9 phút, sau đó bè bạn của bạn click vào link trên và cũng triển khai hành vi tựa như, … Vòng lặp này cứ tiếp nối cho đến khi hàng loạt mạng xã hội facebook đều thấy Open link video full 9 phút 😆Thực tế, với sự bảo vệ của CORS, Facebook sẽ chỉ được cho phép những request với Origin ( đính kèm trong request header ) là facebook.com lên server của họ. Tức là chỉ có request thực thi từ website facebook.com mới được đồng ý. Hay nói cách khác, họ đã số lượng giới hạn việc san sẻ tài nguyên giữa những tên miền khác nhau ( cross-origin resource sharing ) .

Bạn cũng có thể tự hỏi:

– ” Vậy nếu website của hacker cố ý biến hóa header origin khi gửi request thì sao ? “. Đúng, họ hoàn toàn có thể làm như vậy. Nhưng trình duyệt sẽ tự động hóa bỏ lỡ và chỉ gửi lên origin thực sự ( là tên miền của website thực thi request ) .- ” Vậy nếu request được triển khai từ phía server chứ không phải client ? “. Trong trường hợp này hacker hoàn toàn có thể vượt qua được CORS nhưng họ lại không hề gửi kèm được authentication cookie do tại nó nằm ở phía client .

Content Security Policy (CSP)

Để hiểu về CSP (chính sách bảo mật nội dung), trước tiên chúng ta cần tìm hiểu về một lỗ hổng rất thông dụng trên web, đó là XSS (cross–site scripting, ký hiệu X thay cho C để tránh nhầm lẫn với CSS 😀). XSS là khi kẻ xấu nhúng code Javascript vào trong code phía client của bạn.

Bạn hoàn toàn có thể nghĩ rằng : ” Nhúng code Javascript vào thì làm được gì ? Thay đổi màu chữ từ đỏ sang xanh ? … “Giả sử một ai đó nhúng được code Javascript vào website mà bạn đang truy vấn. Khi đó họ hoàn toàn có thể :

• Giả dạng bạn để thực hiện một HTTP request.
• Nhúng 1 iframe trông như 1 phần website và yêu cầu bạn nhập mật khẩu rồi gửi request đến server của hacker.
• Chèn hoặc sửa một đường dẫn trên website gốc, dẫn đến một website giả mạo với giao diện giống hệt website gốc để thực hiện hành vi lừa đảo (ví dụ yêu cầu đăng nhập, yêu cầu nhập thông tin tài khoản, …)

… và muôn vàn năng lực khác .

CSP sẽ cố gắng ngăn chặn điều này ngay từ đầu bằng cách giới hạn:

• Cái gì có thể được phép mở trong một iframe.
• Style nào có thể được tải.
• Request có thể được thực hiện ở đâu.
• …

Vậy nó hoạt động như nào?

Khi bạn bấm vào một đường link hoặc gõ địa chỉ website trên trình duyệt thì trình duyệt sẽ thực thi một GET request. Và server sẽ trả về HTML kèm theo một vài HTTP headers. Nếu bạn muốn biết mình nhận được header như nào thì hãy bật tab Network trong DevTools và truy vấn thử một website. Bạn hoàn toàn có thể sẽ thấy một response header như sau :

content-security-policy:

default-src * data: blob:;

script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';

style-src data: blob: 'unsafe-inline' *;

connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;

Đó là chủ trương bảo mật nội dung của Facebook. Tìm hiểu chi tiết cụ thể hơn những directives ( thông tư ) :

– default-src: Hạn chế tất cả các CSP directive mà không được liệt kê rõ ràng.

– script-src: Giới hạn những script có thể được load.

– style-src: Giới hạn những style có thể được load.

– connect-src: Giới hạn những URL nào có thể được load sử dụng script như fetch, XHR, ajax, …

Có nhiều CSP directive khác nữa ngoài 4 cái ở trên. Trình duyệt sẽ đọc CSP header và vận dụng hàng loạt những directive đó cho mọi thứ trên trang HTML .

HTTPS hay HTTP Secure

Chắc chắn bạn đã từng nghe nói đến HTTPS. Có thể bạn nghe nói rằng Chrome sẽ lưu lại website của bạn là không bảo đảm an toàn ( insecure ) nếu nó không có HTTPS .Về thực chất thì HTTPS khá đơn thuần. HTTPS thì được mã hóa còn HTTP thì không .

Vậy cái này thì có liên quan gì nếu như bạn không gửi những dữ liệu nhạy cảm? Hãy cùng tìm hiểu thêm về một thuật ngữ khác: MITM (Man in the Middle).

Nếu bạn đang sử dụng Wi-Fi công cộng ( không đặt mật khẩu ) ở một quán cafe, một ai đó hoàn toàn có thể thuận tiện bắt được request của bạn. Nếu tài liệu của bạn không được mã hóa, họ hoàn toàn có thể đọc được làm bất kỳ thứ gì họ muốn. Họ hoàn toàn có thể chỉnh sửa HTML, CSS hoặc Javascript trước khi trình duyệt của bạn nhận được tài liệu. Tương tự như XSS ở trên, bạn hoàn toàn có thể tưởng tượng được hacker hoàn toàn có thể làm được những gì .Sử dụng HTTPS thì mọi tài liệu truyền và nhận giữa máy tính của bạn và server đều được mã hóa khiến cho hacker không hề đọc hay chỉnh sửa tùy ý được .

HTTP Strict-Transport-Security (HSTS)

Tiếp tục sử dụng Facebook header làm ví dụ :

strict-transport-security: max-age=15552000; preload

Header trên chỉ vận dụng nếu bạn truy vấn trang sử dụng HTTPS :

• max-age: Chỉ định thời gian trình duyệt ghi nhớ để bắt buộc người dùng truy cập website bằng HTTPS.
• preload: Không quan trọng lắm với mục đích của chúng ta, nó là một dịch vụ được host bởi Google.

Giả sử bạn truy vấn trang Facebook lần tiên phong và bạn biết HTTPS bảo đảm an toàn hơn HTTP nên bạn truy vấn qua HTTPS. Khi trình duyệt nhận được header trên nó sẽ ghi nhớ chuyển hướng những request sau này của bạn về HTTPS. Một tháng sau có ai đó gửi cho bạn một link đến Facebook sử dụng HTTP và bạn bấm vào nó. Do 1 tháng thì nhỏ hơn 15552000 giây ( giá trị của max-age ) nên trình duyệt sẽ gửi request dưới dạng HTTPS để tránh tiến công MITM .

Tổng kết

Bảo mật web rất quan trọng bất kể bạn làm ở vị trí nào trong mảng tăng trưởng web. Bạn càng tiếp xúc, càng tìm hiểu và khám phá nó kỹ hơn thì bạn càng có lợi .

Bảo mật nên là thứ quan trọng với tất cả mọi người chứ không chỉ riêng những chuyên gia bảo mật 👮.

Nguồn : https://medium.freecodecamp.org/a-quick-introduction-to-web-security-f90beaf4dd41

Source: https://vh2.com.vn
Category: Bảo Mật