Lỗ hổng bảo mật là gì? Những lỗ hổng bảo mật phổ biến hiện nay

Lỗ hổng bảo mật là gì?

Trong an ninh mạng, lỗ hổng bảo mật (vulnerability) là các điểm yếu mà các tội phạm mạng có thể lợi dụng khai thác để truy cập trái phép vào hệ thống máy tính. Sau khi khai thác được lỗ hổng, một cyberattack có thể phát tán các mã độc, cài đặt malware hay thậm chí là đánh cắp các dữ liệu nhạy cảm.

Các lỗ hổng bảo mật có thể bị khai thác bằng nhiều phương pháp khác nhau, trong đó có SQL injection, buffer overflow, cross-site scripting (XSS) hay open source exploit kit – tìm kiếm các điểm yếu bảo mật ở trong ứng dụng web.

Có nhiều lỗ hổng bảo mật có thể tác động tiêu cực đến phần mềm lớn, khiến nhiều khách hàng sử dụng phần mềm có nguy cơ cao bị vi phạm dữ liệu hay tấn công vào chuỗi cung ứng. Trong đó có zero-day, được MITER đánh giá là một CVE (Common Vulnerability Exposure).

Những cơ quan an ninh mạng

Lỗ hổng bảo mật có thể được định nghĩa theo nhiều cách khác nhau. Dưới đây là cách một số cơ quan an ninh mạng lớn định nghĩa lỗ hổng bảo mật là gì:

• Viện Tiêu Chuẩn và Công nghệ Quốc gia NIST: Lỗ hổng bảo mật là những điểm yếu tồn tại trong một hệ thống thông tin, quy trình bảo mật hệ thống, kiểm soát nội bộ hay triển khai có thể bị khai thác bởi những nguồn đe dọa.
• ISO 27005: Là những điểm yếu của một asset hay nhóm các asset có thể bị khai thác bởi một hay nhiều mối đe dọa mạng (cyber threat). Trong đó asset (tài sản) có thể là bất kỳ thứ gì có giá trị đối với các tổ chức, hoạt động kinh doanh và tính liên tục của tổ chức.
• IETF RFC 4949: Lỗ hổng bảo mật là một lỗi hay điểm yếu trong thiết kế, triển khai hoặc cách vận hành và quản lý của hệ thống. Những yếu tố này có thể bị lợi dụng để vi phạm cách chính sách bảo mật của hệ thống.
• ENISA: Là sự tồn tại của các điểm yếu, lỗi thiết kế hay triển khai có thể dẫn đến những việc không mong muốn, gây ảnh hưởng đến bảo mật của hệ thống máy tính, mạng, ứng dụng hay giao thức có liên quan.
• The Open Group: Là xác suất mà khả năng của mối đe dọa vượt quá khả năng chống lại chúng.
• ISACA: Là những điểm yếu trong thiết kế, triển khai, việc vận hành hay kiểm soát nội bộ.

Khi nào thì các lỗ hổng đã biết nên được công khai?

Việc công khai về các lỗ hổng bảo mật đã biết là một vấn đề nóng trong lĩnh vực liên quan đến bảo mật. Có hai lựa chọn cho vấn đề này là:

Tiết lộ lỗ hổng nhanh chóng, đầy đủ

Có nhiều chuyên gia an ninh mạng (Cyber Security) cho rằng nên tiết lộ nhanh chóng các lỗ hổng bảo mật đã biết, bao gồm cả những thông tin cụ thể về cách khai thác các lỗ hổng này. Họ cho rằng việc này giúp phần mềm an toàn hơn và bản vá sẽ được phát hành sớm hơn. Từ đó bảo vệ được phần mềm, ứng dụng, hệ điều hành và cả thông tin.

Giới hạn hoặc không công khai lỗ hổng

Tuy nhiên, cũng có nhiều chuyên gia khác lại cho rằng việc tiết lộ các lỗ hổng bảo mật đã biết là không nên, vì lỗ hổng sau đó có thể bị khai thác. Bên cạnh đó, họ cũng cho rằng giới hạn thông tin cũng giúp giảm nguy cơ bị khai thác lỗ hổng này.

Dĩ nhiên, mỗi ý kiến đều có cái lý của riêng nó. Dù vậy, hãy luôn nhận thức được rằng: những kẻ tấn công và cybercriminal hiện nay thường xuyên tìm kiếm các lỗ hổng đã biết và kiểm tra cách để khai thác chúng.

Ngày nay, nhiều công ty đã triển khai những nhóm bảo mật nội bộ để kiểm tra bảo mật IT, cùng với những biện pháp bảo mật khác của tổ chức. Tất cả đều nằm trong quy trình đánh giá rủi ro an ninh mạng và quản lý rủi ro thông tin tổng thể của công ty.

Sự khác nhau giữa lỗ hổng bảo mật và rủi ro bảo mật

Rủi ro an ninh mạng thường được phân loại là một trong số những lỗ hổng bảo mật. Tuy nhiên, về bản chất thì chúng không giống nhau đến như vậy. Nói một cách đơn giản, hãy xem rủi ro bảo mật là xác suất và tác động của một lỗ hổng bảo mật bị khai thác.

Nếu tác động và xác suất lỗ hổng bị khai thác thấp, thì rủi ro sẽ thấp. Ngược lại, nếu tác động và xác suất lỗ hổng bị khai thác cao, thì rủi ro bảo mật cũng sẽ cao.

Và do đó, có những trường hợp dù tồn tại lỗ hổng, nhưng lại không gây ra rủi ro bảo mật. Một ví dụ đơn giản là khi lỗ hổng nào đó không hề có giá trị đối với doanh nghiệp, tổ chức.

Khi nào thì lỗ hổng bảo mật có thể được khai thác?

Nếu lỗ hổng bảo mật có ít nhất một vector tấn công đã biết và đang hoạt động thì lỗ hổng đó có thể bị khai thác. “Window of vulnerability” là một thuật ngữ để chỉ khoảng thời gian từ khi lỗ hổng được biết cho đến khi nó đã được vá.

Nếu tổ chức có phương pháp bảo mật mạnh, thì tổ chức sẽ ít có lỗ hổng có khả năng bị khai thác hơn. Giả sử, nếu tổ chức được cấu hình bảo mật S3 đúng cách thì khả năng dữ liệu bị rò rỉ sẽ thấp hơn.

Tương tự, ta cũng có thể giảm các rủi ro ở bên thứ ba bằng những chiến thuật quản lý rủi ro (third-party risk management và vendor risk management).

Zero-day exploit là gì?

Zero-day exploit là việc khai thác các lỗ hổng zero-day. Trong đó, một lỗ hổng bảo mật zero-day là một lỗ hổng chưa được xác định, hoặc chưa được khắc phục.

Trước khi lỗ hổng được vá, các hacker có thể khai thác nó để gây ảnh hưởng xấu đến chương trình máy tính, kho dữ liệu, máy tính hay mạng.

“Day Zero” chính là ngày mà lỗ hổng bảo mật được biết, từ đó thực hiện vá lỗ hổng này để tránh bị khai thác.

Nguyên nhân gây ra lỗ hổng bảo mật

Có nhiều nguyên nhân khác nhau có thể dẫn đến những lỗ hổng bảo mật. Trong đó có thể kể đến như:

• Hệ thống phức tạp: Những hệ thống có độ phức tạp cao có thể làm tăng khả năng xảy ra lỗi, cấu hình sai hoặc xuất hiện những truy cập ngoài ý muốn.
• Sự phổ biến: Những code, phần mềm, hệ điều hành, phần cứng… phổ biến thường giúp các hacker dễ tìm thấy lỗ hổng bảo mật hệ thống hơn.
• Tính kết nối: Các thiết bị được kết nối càng nhiều thì khả năng xuất hiện lỗ hổng càng cao.
• Quản lý mật khẩu kém: Các mật khẩu yếu có thể bị phá bằng brute force, đồng thời người dùng cũng cần tránh sử dụng cùng 1 mật khẩu trong nhiều hệ thống.
• Lỗi hệ điều hành: Giống như mọi phần mềm, hệ điều hành cũng hoàn toàn có thể xuất hiện những sai sót. Theo mặc định, các hệ điều hành thực chất không hề an toàn vì nó cho người dùng quyền truy cập rất rộng, từ đó virus và malware có thể xâm nhập để thực thi những lệnh độc hại.
• Sử dụng internet: Internet chứa rất nhiều sypware và adware, có thể được cài đặt tự động ở trên máy tính.
• Lỗi phần mềm: Các programmmer có thể vô tình hay cố ý để lại một số lỗ hổng phần mềm có thể bị khai thác.
• User input không được kiểm tra: Nếu trang web hay phần mềm không kiểm tra những dữ liệu đầu vào, thì chúng có thể thực thi các lệnh SQL ngoài ý muốn.
• Con người: Lỗ hổng lớn nhất trong mọi hệ thống thuộc về chính người dùng ở trong hệ thống. Trong đó, social engineering là một trong những mối đe dọa lớn nhất với phần lớn các tổ chức.

Quản lý lỗ hổng bảo mật là gì?

Quản lý lỗ hổng bảo mật là một hoạt động theo chu kỳ, nhằm xác định, phân loại, khắc phục và giảm thiểu các lỗ hổng. Các giai đoạn quan trọng của việc quản lý là phát hiện lỗ hổng, đánh giá lỗ hổng, và khắc phục lỗ hổng.

Một số phương pháp phát hiện lỗ hổng bảo mật là:

• Quét lỗ hổng.
• Penetration Testing (PenTest).
• Google hacking.

Sau khi lỗ hổng được tìm thấy, chúng ta sẽ tiếp tục với bước đánh giá lỗ hổng:

• Xác định lỗ hổng: Phân tích các bản scan mạng, kết quả pentest, các file log của firewall và kết quả scan lỗ hổng để tìm ra những điểm bất thường mà có thể xảy ra cyberattack.
• Xác minh lỗ hổng: Tiếp đến, ta cần xác định xem lỗ hổng có khả năng bị khai thác hay không, đồng thời phân loại mức độ nghiêm trọng của việc khai thác để nhận thức rõ được độ rủi ro.
• Giảm thiểu các lỗ hổng bảo mật: Quyết định các biện pháp đối phó và biện pháp hiệu quả, đặc biệt là trong trường hợp không có bản vá.
• Khắc phục lỗ hổng bảo mật: Thường xuyên cập nhật phần mềm hoặc phần cứng bị ảnh hưởng nếu có thể.

Hiện nay, các cuộc tấn công mạng đang ngày càng phát triển và xuất hiện nhiều hơn. Do đó, việc quản lý các lỗ hổng bảo mật phải liên tục được thực hiện để đảm bảo tổ chức, doanh nghiệp.

Quét lỗ hổng bảo mật là gì?

Vulnerability scanner là các phần mềm được thiết kế để đánh giá máy tính, mạng và ứng dụng để tìm những lỗ hổng bảo mật đã biết. Các phần mềm này có thể xác định và phát hiện ra những lỗ hổng phát sinh vì cấu hình sai hoặc lập trình không đúng ở trong mạng. Đồng thời cũng có thể thực hiện quét xác thực (authenticated scan) và quét không xác thực (unauthenticated scan):

• Authenticated scan: Cho phép các scanner truy cập trực tiếp vào trong nội dung được kết nối mạng bằng các giao thức quản trị từ xa như SSH hay RDP, đồng thời xác thực bằng các thông tin đăng nhập hệ thống đã được cung cấp. Khi đó, các scanner có thể truy cập vào những dữ liệu cấp thấp như các dịch vụ cụ thể, chi tiết cấu hình, cung cấp những thông tin chi tiết và chính xác về hệ điều hành, các phần mềm đã cài, lỗi cấu hình hay những bản vá còn thiếu.
• Unauthenticated scan: Cách xác thực này chủ yếu được sử dụng bởi những kẻ tấn công mạng hay các nhà phân tích bảo mật để kiểm thử và xác định bảo mật của những asset bên ngoài hoặc tìm ra những dữ liệu có khả năng bị rò rỉ.

Tìm hiểu thêm: SSH là gì

Sơ lược về PenTest

Penetration testing (pen testing hay pentest) là một hoạt động kiểm tra IT asset để tìm ra các lỗ hổng bảo mật mà kẻ tấn công có thể khai thác. Pentest có thể được tự động hòa bằng các phần mềm hoặc thực hiện thủ công.

Dù bằng cách nào đi chăng nữa, thì mục đích chính của pentest là thu thập thông tin về mục tiêu, xác định các lỗ hổng có thể xảy ra và khai thác chúng để thu thập báo cáo.

Bên cạnh đó, pentest cũng có thể được sử dụng để kiểm tra các chính sách bảo mật của tổ chức, sự tuân thủ theo các yêu cầu, nhận thức về an ninh mạng của các nhân viên trong tổ chức. Cùng với đó là khả năng xác định và ứng phó với các sự cố bảo mật của tổ chức.

Tìm hiểu về Google hacking

Tiếp đến, hãy cũng tìm hiểu sơ qua về Google hacking. Thuật ngữ này dùng để chỉ việc sử dụng một công cụ tìm kiếm, chẳng hạn như Google hay Bing để xác định các lỗ hổng bảo mật. Google hacking có thể được thực hiện thông qua việc sử dụng các toán tử tìm kiếm nâng cao trong những truy vấn định vị thông tin khó tìm, hoặc những thông tin vô tình bị lộ do cloud service bị cấu hình sai. Các nhà nghiên cứu bảo mật và những kẻ tấn công thường sử dụng các truy vấn này để định vị những thông tin nhạy cảm.

Các lỗ hổng thường được chia thành hai loại như sau:

1. Lỗ hổng phần mềm.
2. Cấu hình sai.

Do đó, những kẻ tấn công có xu hướng tìm kiếm các cấu hình người dùng không chính xác mà chúng đã biết cách khai thác. Sau đó chỉ cần quét các hệ thống có những lỗ hổng bảo mật đã biết.

Để ngăn chặn Google hacking, ta cần đảm bảo mọi dịch vụ cloud đều được cấu hình chính xác. Một khi có bất kỳ thông tin nào bị rò rỉ trên Google, nó sẽ bị công khai nhanh chóng.

Cơ sở dữ liệu lỗ hổng bảo mật

Cơ sở dữ liệu (CSDL) lỗ hổng bảo mật là một nền tảng có nhiệm vụ thu thập, duy trì và chia sẻ thông tin về các lỗ hổng đã được phát hiện. MITRE hiện đang điều hành CVE và sử dụng điểm CVSS (Common Vulnerability Scroring System) để phản ánh nguy cơ tiềm ẩn mà lỗ hổng bảo mật có thể gây hại cho tổ chức. Danh sách các CVE này chính là nền tảng vững chắc cho nhiều vulnerability scanner.

Lợi ích của lỗ hổng trong Cơ sở dữ liệu là nó cho phép các tổ chức phát triển, ưu tiên và thực hiện các bản vá cũng như nhiều biện pháp khác để giảm thiểu và khắc phục những lỗ hổng nghiêm trọng.

Một số lỗ hổng phổ biến trong cơ sở dữ liệu:

• Lỗi triển khai: Nếu Cơ sở dữ liệu không được kiểm soát nghiêm ngặt, các lỗ hổng của nó có thể giúp cho các hacker xâm nhập được vào hệ thống. Đồng thời, việc kiểm soát bảo mật kém, mật khẩu yếu hay không thay đổi cài đặt bảo mật mặc định có thể làm lộ những dữ liệu nhạy cảm.
• SQL injection: Những cuộc tấn công vào cơ sở dữ liệu thường xảy ra ở những CSDL có nhiều lỗ hổng bảo mật.
• Audit không đầy đủ: Nếu không thực hiện audit, việc kiểm tra xem dữ liệu có bị sửa đổi hay truy cập hay không là rất khó. Các cơ sở dữ liệu lỗ hổng bảo mật cũng đã quyết định rằng việc audit tracking là một biện pháp ngăn chặn cyber attack.

Một số ví dụ của lỗ hổng bảo mật

Các lỗ hổng bảo mật có thể được phần thành 6 loại chính như sau:

1. Phần cứng

Phần cứng nhạy cảm với độ ẩm, bụi, mã hóa kém hoặc do lỗ hổng ở trong firmware.

2. Phần mềm

Kiểm tra không đầy đủ, thiếu adit, lỗi thiết kế, vi phạm an toàn bộ nhớ (buffer overflow, over-read, dangling pointer), lỗi xác thực input (code injection, XSS, directory traversal, email injection, format string attack, HTTP header injection, HTTP response splitting, SQL injection), sai đặc quyền (clickjacking, cross-site request forgery, FTP bounce attack), race condition – điều kiện thực hiện (symlink races, time-of-check-to-time-of-use bug), side channel attack, timing attack hay lỗi user interface.

3. Mạng

Thường do đường truyền không được bảo đảm, tấn công man-in-the-middle, kiến trúc mạng không an toàn, thiếu xác thực hoặc không chỉnh sửa xác thực mặc định.

4. Nhân sự

Chính sách tuyển dụng kém, thiếu nhận thức vào đào tạo về bảo mật, tuân thủ bảo mật kém, quản lý mật khẩu không tốt hay do tải phần mềm độc hại qua các file đính kèm trong email.

5. Trang vật lý

Các vùng bị ảnh hưởng bởi thiên tai, nguồn điện không đảm bảo hoặc không có keycard.

6. Tổ chức

Thiếu kế hoạch audit, bảo mật hoặc ứng phó sự cố.

10 lỗ hổng website phổ biến nhất

Trước hết, Vietnix muốn bạn phân biệt rõ ràng hai thuật ngữ “authorization” (ủy quyền) và “authentication” (xác thực). Có rất nhiều người nhầm lần hai khai niệm nay, thậm chí chúng còn đều được viết tắt thành “auth”, nên vấn đề dường như ngày càng phức tạp hơn. Vì vậy, trước khi tìm hiểu về các lỗ hổng website phổ biến, hãy xác định rõ như sau:

• Authentication: Là việc xác minh một người là người dùng cụ thể, vì họ đã cung cấp chính xác thông tin xác thực bảo mật của họ (như mật khẩu, câu hỏi bảo mật, vân tay…).
• Authorization: Là việc xác nhận một người dùng có quyền truy cập vào một tài nguyên nào đó, hoặc người dùng đó được cấp quyền để thực hiện một hành động cụ thể.

Tóm gọn lại, thì authentication là biết được một thực thể nào đó là ai, còn authorization là biết được thực thể đó có thể làm gì. Bây giờ, hãy cũng tìm hiểu về cách tìm lỗ hổng website, và cách ngăn chặn 10 lỗ hổng website phổ biến nhất hiện nay.

1. Injection flaw

Injection flaw xuất phát từ một lỗi cổ điển trong việc lọc các input không đáng tin cậy. Lỗi này có thể xảy ra khi chuyển dữ liệu chưa được lọc đến server SQL (SQL injection), đến trình duyệt (XSS), LDAP server (LDAP injection) hay đến bất kỳ đâu. Vấn đề là, các hacker có thể inject lệnh vào trong những thực thể này, từ đó có thể đánh cắp dữ liệu người dùng. Hoặc thậm chí là chiếm quyền điều khiển trình duyệt của client.

Mọi thứ mà người dùng nhận được từ các nguồn không đáng tin cậy đều phải được lọc, tốt nhất là theo một whitelist. Ta không nên sử dụng blacklist, vì việc xử lý rất khó, mà lại thường tương đối dễ bypass. Các phần mềm antivirus chủ yếu cung cấp các ví dụ điển hình về lỗi blacklist. Còn pattern machine thì không vận hành được.

Cách ngăn chặn: May mắn là việc phòng chống injection không quá phức tạp, chỉ cần lọc các input đúng cách và cân nhắc xem các input có đáng tin cậy hay không. Tuy nhiên, mọi input đều cần được lọc đúng cách và chắc chắn.

Giả sử, ta có một hệ thống với 1.000 input, và việc lọc 999 input là vẫn chưa đủ! Vì vẫn còn một và dù chỉ một input chưa được lọc, vẫn hoàn toàn có khả năng tấn công vào hệ thống. Ngoài ra ta cũng có thêm một truy vấn SQL vào truy vấn khác, nếu Cơ sở dữ liệu đáng tin cậy. Đây được gọi là Second Order SQL injection.

Việc lọc là tương đối khó (chẳng hạn như crypto), nhưng tốt nhất thì hãy dựa vào chức năng lọc trong framework của mình. Bởi vì chúng đã được kiểm tra kỹ lưỡng và có thể hoạt động tốt.

2. Broken Authentication

Lỗ hổng này bao gồm việc các lỗi có thể xảy ra ở trong quá trình xác thực, và không hẳn có cùng một nguyên nhân. Dưới đây là một số lý do phổ biến cho lỗi này:

• URL chứa session ID và rò rỉ nó trong referer header đến một người khác.
• Mật khẩu không được mã hóa khi lưu trữ hoặc chuyển tiếp.
• Session ID có thể đoán được, do đó việc giành được quyền truy cập dù là rất nhỏ.
• Có thể có cố định session.
• Xảy ra xâm nhập session, hoặc timeout không được triển khai đúng, hay do sử dụng HTTP (không có bảo mật SSL),…

Cách ngăn chặn: Cách đơn giản nhất để ngăn chặn các lỗ hổng xảy ra trong quá trình xác minh chính là sử dụng một framework.

3. Cross-Site Scripting (XSS)

Đây là một lỗi khá phổ biến liên quan đến việc xác thực input (về cơ bản thì đây là một trường hợp đặc biệt của lỗi thứ nhất trong bài viết này). Các hacker cung cấp cho ứng dụng web các JavaScript tag trong input, khi input này được trả lại người dùng mà không được xác thực, trình duyệt sẽ thực thi nó.

Cách ngăn chặn: Có một giải pháp bảo mật web tương đối đơn giản là: không gửi lại HTML tag cho client. Ngoài ra, việc này còn giúp chống lại HTML injection – một loại tấn công mà hacker sẽ đưa HTML content, tương đối khó chịu dù ảnh hưởng đến trang web là không quá lớn. Thông thường, giải pháp đơn giản là chuyển đổi tất cả thực thể HTML, chẳng hạn như <script> được trả về dưới dạng <script>. Một phương pháp khác là sử dụng các biểu thức để loại bỏ HTML tag bằng < và >, tuy nhiên cách này khá nguy hiểm vì nhiều trình duyệt sẽ cho rằng HTML đang bị hỏng.

4. Tham chiếu đối tượng trực tiếp không an toàn

Lỗi này xảy ra chủ yếu do quá tin tưởng vào input của người dùng, và cái giá phải trả là một lỗ hổng bảo mật trong website. Tham chiếu đối tượng trực tiếp là khi có một đối tượng ở trong, như file hay key Cơ sở dữ liệu được expose cho người dùng. Khi đó, hacker có thể cung cấp tham chiếu này, và nếu không có ủy quyền thì chúng có thể truy cập vào hệ thống.

Giả sử ta có một module download.php, cho phép người dùng download các file , sử dụng tham số CGI để chỉ định tên file (như download.php?file=vietnix.txt). Nếu developer bỏ qua authorization khỏi code, các hacker có thể dùng nó để download mọi file hệ thống mà người dùng chạy PHP có quyền truy cập. Chẳng hạn như code ứng dụng hay những bản sao lưu,…

Cách ngăn chặn: Ủy quyền cho người dùng đúng cách và nhất quán, đồng thời whitelist các lựa chọn. Ngoài ra, ta cũng có thể ngăn chặn bằng cách lưu trữ dữ liệu ở trong, không phụ thuộc vào việc nó được truyền từ client thông qua tham số CGI. Hầu hết các biến session trong framework đều phù hợp cho mục đích này.

5. Cấu hình bảo mật không chính xác

Thành thật mà nói, có lẽ số lượng web server và ứng dụng bị cấu hình sai còn nhiều hơn là số lượng được cấu hình chính xác. Sau đây là một số ví dụ phổ biến:

• Chạy ứng dụng khi đang enable tính năng debug trong sản xuất.
• Directory listing đang được bật ở trên server, dẫn đến việc rò rỉ những thông tin quan trọng.
• Đang chạy phần mềm lỗi thời (các plugin WordPress, phpMyAdmin cũ,…)
• Không chạy những dịch vụ cần thiết ở trên máy.
• Không thay đổi default key và password (Rất phổ biến!).
• Tiết lộ thông tin xử lý lỗi cho kẻ tấn công, chẳng hạn như stack trace.

Cách ngăn chặn: Xây dựng một process “build and deploy” tốt (nên được tự động hóa) để có thể chạy các test khi deploy.

6. Phơi nhiễm dữ liệu nhạy cảm

Lỗ hổng bảo mật này chủ yếu liên quan đến cypto và bảo vệ tài nguyên. Những dữ liệu nhạy cảm nên được mã hóa mọi lúc, kể cả khi ở trong lưu thông hay không. Đồng thời, thông tin thẻ tín dụng và mật khẩu người dùng cũng cần phải được mã hóa, trong đó mật khẩu nên được hash. Hiển nhiên, thuật toán crypto/hashing cần phải đủ mạnh, nếu băn khoăn thì hãy lựa chọn AES (trên 256 bit) và RSA (2048 bit trở lên).

Và dĩ nhiên, session ID cũng với dữ liệu nhạy cảm không được di chuyển ở trong URL, đồng thời cookies nhạy cảm cũng cần có secure flag.

Cách ngăn chặn:

• Trong các giao dịch: Sử dụng HTTPS với certificate phù hợp và PFS (Perfect Forward Secrecy). Đừng nhận bất kỳ thứ gì thông qua những kết nối không phải HTTPS. Đồng thời cũng cần có secure flag ở trên cookies.
• Trong việc lưu trữ: Việc này thì sẽ khó hơn. Trước phần, cần hạn chế tiếp xúc với những thông tin nhạy cảm. Đừng bao giờ lưu trữ thông tin liên quan đến thẻ tín dụng, hãy đăng kí các bộ xử lý thanh toán như Stripe hay Braintree. Tiếp đến, nếu thật sự cần lưu trữ dữ liệu nhạy cảm nào đó, hãy mã hóa nó và đảm bảo tất cả mật khẩu đều đã được hash. Đối với việc hash, hãy sử dụng bcrypt.

7. Thiếu kiểm soát truy cập cấp chức năng

Đây đơn giản chỉ là một lỗi ủy quyền. Nó xảy ra khi một hàm được gọi ở trên server nhưng việc cấp quyền thích hợp không được thực hiện. Phần lớn các developer dựa vào việc phía server đã có sẵn user interface (UI), và họ nghĩ rằng các chức năng không được cung cấp bởi server thì client cũng chẳng thể truy cập được. Thật ra, sự việc không đơn giản như vậy, vì kẻ tấn công luôn có thể giả mạo các request với chức năng “ẩn” và không hề bị cản trở khi các chức năng không thể truy cập bởi UI.

Hãy tưởng tượng việc này giống như chúng ta có một /admin panel, và các nút chỉ xuất hiện trong UI nếu user admin. Vậy thì các hacker hoàn toàn có thể dễ dàng tấn công và đánh cắp dữ liệu.

Cách ngăn chặn: Ở phía server, hãy luôn thực hiện ủy quyền, chỉ cần như vậy là đủ.

8. Cross Site Request Forgery (CSRF)

Đây là một ví dụ điển hình của deputy attack. Trong đó, trình duyệt bị một số bên thứ ba khác lừa sử dụng sai quyền hạn của mình. Chẳng hạn như một trang web của bên thứ ba có thể thao túng cho trình duyệt của người dùng lạm dụng quyền của mình, nhằm thực hiện những việc có lợi cho kẻ tấn công.

Đối với CSRF, trang web của bên thứ ba sẽ đưa ra các request đến trang web đích (chẳng hạn như ngân hàng của người dùng) bằng trình duyệt với cookies/session của người dùng đó. Nếu đã đăng nhập vào tab của homepage ngân hàng đó, và tab này có thể bị tấn công, thì tab khác có thể làm cho trình duyệt sử dụng sai thông tin đăng nhập. Trong ví dụ này, deputy là trình duyệt sử dụng sai quyền của mình (session cookies) để thực hiện những việc mà hacker yêu cầu.

10. Chuyển hướng và chuyển tiếp chưa được xác thực

Lại là một vấn đề nữa liên quan đến việc lọc các input. Giả sử rằng trang web đích có một module redirect.php, nhận URL là một tham số GET. Việc thao tác với tham số có thể tạo một URL trên targetsite.com, chuyển hướng đến malwareinstall.com. Khi người dùng thấy đường link này, họ sẽ thấy targtsite.com/blahblah, dường như có vẻ đáng tin cậy và sẽ click vào. Tuy nhiên họ lại đang được chuyển hướng đến những trang web độc hại. Ngoài ra, kẻ tấn công cũng có thể chuyển hướng trình duyệt đến những URL như targetsite.com/deleteprofile?confirm=1

Bên cạnh đó, việc nhồi nhét input do người dùng xác định vào một HTTP header cũng có thể dẫn đến header injection.

Cách khắc phục:

• Không chuyển hướng hoàn toàn (hiếm khi cần đến lựa chọn này).
• Có một danh sách tĩnh các vị trí hợp lệ để chuyển hướng.
• Whitelist các tham số do người dùng xác định (tương đối phức tạp).

Lời kết

Vietnix vừa chia sẻ những lổ hỗng bảo mật và cách phòng chống, hy vọng qua bài viết này bạn có thêm nhiều kiến thức hữu ích và có thể ứng dụng những kiến thức này để nâng cao bảo mật dữ liệu cá nhân của bạn một cách an toàn và hiệu quả, chúc bạn thành công!