Khoảng một năm trước, chúng tôi tại DataLine đã ra mắt để tìm kiếm và phân tích các lỗ hổng trong ứng dụng CNTT. Dịch vụ này dựa trên giải pháp đám mây Qualys, về hoạt động của nó . Trong suốt một năm làm việc với giải pháp này, chúng tôi đã tiến hành quét 291 trang web khác nhau và tích lũy số liệu thống kê về các lỗ hổng phổ biến trong ứng dụng web.
Trong bài viết dưới đây tôi sẽ cho bạn thấy chính xác những lỗ hổng bảo mật trang web nào được ẩn giấu đằng sau các mức độ nghiêm trọng khác nhau. Chúng ta hãy xem máy quét thường xuyên tìm thấy những lỗ hổng nào, tại sao chúng có thể xảy ra và cách tự bảo vệ mình.
Qualys chia tất cả các lỗ hổng ứng dụng web thành ba mức độ nghiêm trọng: thấp, trung bình và cao. Nếu nhìn vào sự phân bổ theo “mức độ nghiêm trọng”, có vẻ như mọi thứ không quá tệ. Có một số lỗ hổng có mức độ nghiêm trọng cao, hầu hết đều không nghiêm trọng:
Nhưng không phê bình không có nghĩa là vô hại. Chúng cũng có thể gây ra thiệt hại nghiêm trọng.
Các lỗ hổng “không nghiêm trọng” hàng đầu
- Lỗ hổng nội dung hỗn hợp.
Tiêu chuẩn bảo mật trang web là truyền dữ liệu giữa máy khách và máy chủ thông qua giao thức HTTPS, hỗ trợ mã hóa và bảo vệ thông tin khỏi bị đánh chặn.
Một số trang web sử dụng nội dung hỗn hợp: Một số dữ liệu được truyền qua giao thức HTTP không an toàn. Đây là cách nó thường được truyền đạt nhất nội dung thụ động – thông tin chỉ ảnh hưởng đến việc hiển thị của trang web: hình ảnh, kiểu css. Nhưng đôi khi đây là cách nó được truyền đi nội dung hoạt động: các tập lệnh kiểm soát hoạt động của trang web. Trong trường hợp này, bằng cách sử dụng phần mềm đặc biệt, bạn có thể phân tích thông tin có nội dung hoạt động đến từ máy chủ, sửa đổi phản hồi của mình một cách nhanh chóng và làm cho máy hoạt động theo cách mà người tạo ra nó không mong muốn.
Các phiên bản trình duyệt mới hơn cảnh báo người dùng rằng các trang web có nội dung hỗn hợp không an toàn và chặn nội dung đó. Các nhà phát triển trang web cũng nhận được cảnh báo của trình duyệt trong bảng điều khiển. Ví dụ: nó trông như thế này :
Có gì nguy hiểm: Những kẻ tấn công sử dụng giao thức không an toàn để chặn thông tin người dùng, thay thế tập lệnh và thay mặt họ gửi yêu cầu đến trang web. Ngay cả khi khách truy cập trang web không nhập dữ liệu, điều này cũng không bảo vệ anh ta khỏi lừa đảo – lấy thông tin bí mật bằng các phương pháp gian lận. Ví dụ: bằng cách sử dụng tập lệnh, bạn có thể chuyển hướng người dùng đến một trang web không an toàn giả dạng trang web quen thuộc với người dùng. Trong một số trường hợp, trang web độc hại trông thậm chí còn đẹp hơn trang gốc và người dùng có thể tự điền vào biểu mẫu và gửi dữ liệu bí mật.Những điều nhà phát triển web nên nhớ: Ngay cả khi quản trị viên trang web đã cài đặt và định cấu hình chứng chỉ SSL/TLS, lỗ hổng vẫn có thể phát sinh do lỗi của con người. Ví dụ: nếu trên một trong các trang bạn không đặt liên kết tương đối mà là liên kết tuyệt đối từ http và ngoài ra bạn chưa thiết lập chuyển hướng từ http sang https.
Bạn có thể phát hiện nội dung hỗn hợp trên một trang web bằng trình duyệt: tìm kiếm mã nguồn của trang, đọc thông báo trong bảng điều khiển dành cho nhà phát triển. Tuy nhiên, nhà phát triển sẽ phải mày mò code rất lâu và tẻ nhạt. Bạn có thể tăng tốc quá trình bằng các công cụ phân tích tự động, ví dụ: , phần mềm Lighthouse miễn phí hoặc phần mềm trả phí Screaming Frog SEO Spider.
Ngoài ra, lỗ hổng còn có thể phát sinh do vấn đề với Legacy-code - mã được kế thừa. Ví dụ: nếu một số trang được tạo bằng mẫu cũ, mẫu này không tính đến việc chuyển trang web sang https.
- Cookie không có cờ "HTTPOnly" và "secure".
Thuộc tính "HTTPOnly" bảo vệ cookie khỏi bị xử lý bởi các tập lệnh mà kẻ tấn công sử dụng để đánh cắp dữ liệu người dùng. Cờ "bảo mật" không cho phép gửi cookie ở dạng văn bản rõ ràng. Giao tiếp sẽ chỉ được phép nếu giao thức HTTPS an toàn được sử dụng để gửi cookie.
Cả hai thuộc tính đều được chỉ định trong thuộc tính cookie:
Set-Cookie: Secure; HttpOnlyCó gì nguy hiểm: Nếu nhà phát triển trang web không chỉ định các thuộc tính này, kẻ tấn công có thể chặn thông tin của người dùng từ cookie và khai thác nó. Nếu cookie được sử dụng để xác thực và ủy quyền, anh ta sẽ có thể chiếm quyền điều khiển phiên của người dùng và thay mặt anh ta thực hiện các hành động trên trang web.
Những điều nhà phát triển web nên nhớ: Theo quy định, trong các khung phổ biến, các thuộc tính này được đặt tự động. Nhưng vẫn kiểm tra cấu hình web server và đặt flag: Set-Cookie HttpOnly; Chắc chắn.
Trong trường hợp này, thuộc tính “HTTPOnly” sẽ ẩn cookie đối với JavaScript của riêng bạn.
- Các lỗ hổng dựa trên đường dẫn.
Máy quét sẽ báo cáo lỗ hổng như vậy nếu nó tìm thấy một tệp hoặc thư mục trang web có thể truy cập công khai có chứa thông tin bí mật. Ví dụ: nó phát hiện các tệp cấu hình hệ thống riêng lẻ hoặc truy cập vào toàn bộ hệ thống tệp. Tình huống này có thể xảy ra nếu quyền truy cập được đặt không chính xác trên trang web.
Có gì nguy hiểm: Nếu hệ thống tập tin “lỗi”, kẻ tấn công có thể rơi vào giao diện hệ điều hành và cố gắng tìm các thư mục có mật khẩu nếu chúng được lưu trữ ở dạng văn bản rõ ràng (đừng làm vậy!). Hoặc bạn có thể đánh cắp các hàm băm mật khẩu và ép buộc mật khẩu, đồng thời cố gắng nâng cao các đặc quyền trong hệ thống và tiến sâu hơn vào cơ sở hạ tầng.
Những điều nhà phát triển web nên nhớ: Đừng quên quyền truy cập và cấu hình nền tảng, máy chủ web, ứng dụng web để không thể “thoát” khỏi thư mục web.
- Biểu mẫu để nhập dữ liệu nhạy cảm có bật tính năng tự động điền.
Nếu người dùng thường xuyên điền vào biểu mẫu trên trang web, trình duyệt của họ sẽ lưu trữ thông tin này bằng tính năng tự động điền.
Biểu mẫu trên trang web có thể bao gồm các trường có thông tin nhạy cảm, chẳng hạn như mật khẩu hoặc số thẻ tín dụng. Đối với các trường như vậy, bạn nên tắt chức năng tự động điền biểu mẫu trên chính trang web.
Có gì nguy hiểm: Nếu trình duyệt của người dùng lưu trữ thông tin nhạy cảm, kẻ tấn công có thể chặn thông tin đó sau, chẳng hạn như thông qua lừa đảo. Về bản chất, một nhà phát triển web đã quên mất sắc thái này đang thiết lập người dùng của mình.
Những điều nhà phát triển web nên nhớ: Trong trường hợp này, chúng ta có một xung đột kinh điển: tiện lợi và bảo mật. Nếu một nhà phát triển web đang nghĩ đến trải nghiệm người dùng, anh ta có thể chọn tính năng tự động hoàn thành một cách có ý thức. Ví dụ, nếu điều quan trọng là phải tuân theo – khuyến nghị về khả năng tiếp cận nội dung cho người dùng khuyết tật.
Đối với hầu hết các trình duyệt, bạn có thể tắt tính năng tự động hoàn thành bằng thuộc tính autocompete="off", ví dụ:
<body> <form action="/vi/form/submit" method="get" autocomplete="off"> <div> <input type="text" placeholder="First Name"> </div> <div> <input type="text" id="lname" placeholder="Last Name" autocomplete="on"> </div> <div> <input type="number" placeholder="Credit card number"> </div> <input type="submit"> </form> </body>Nhưng nó sẽ không hoạt động với Chrome. Điều này được khắc phục bằng cách sử dụng JavaScript, có thể tìm thấy một biến thể của công thức .
- Tiêu đề X-Frame-Options không được đặt trong mã trang web.
Tiêu đề này ảnh hưởng đến các thẻ khung, iframe, nhúng hoặc đối tượng. Với sự trợ giúp của nó, bạn hoàn toàn có thể cấm nhúng trang web của mình vào một khung. Để thực hiện việc này, bạn cần chỉ định giá trị X-Frame-Options: từ chối. Hoặc bạn có thể chỉ định X-Frame-Options: Sameorigin, sau đó việc nhúng vào iframe sẽ chỉ khả dụng trên miền của bạn.
Có gì nguy hiểm: Việc thiếu tiêu đề như vậy có thể được sử dụng trên các trang web độc hại để clickjacking. Đối với cuộc tấn công này, kẻ tấn công tạo ra một khung trong suốt phía trên các nút và đánh lừa người dùng. Ví dụ: những kẻ lừa đảo đóng khung các trang mạng xã hội trên một trang web. Người dùng nghĩ rằng anh ta đang nhấp vào một nút trên trang web này. Thay vào đó, nhấp chuột sẽ bị chặn và yêu cầu của người dùng sẽ được gửi đến mạng xã hội nơi có phiên hoạt động. Đây là cách kẻ tấn công thay mặt người dùng gửi thư rác hoặc thu hút người đăng ký và lượt thích.
Nếu bạn không tắt tính năng này, kẻ tấn công có thể đặt nút ứng dụng của bạn trên một trang web độc hại. Anh ấy có thể quan tâm đến chương trình giới thiệu hoặc người dùng của bạn.
Những điều nhà phát triển web nên nhớ: Lỗ hổng có thể xảy ra nếu X-Frame-Options có giá trị xung đột được đặt trên máy chủ web hoặc bộ cân bằng tải. Trong trường hợp này, máy chủ và bộ cân bằng sẽ chỉ viết lại tiêu đề vì chúng có mức độ ưu tiên cao hơn so với mã phụ trợ.
Các giá trị từ chối và cùng nguồn gốc của tiêu đề X-Frame-Options sẽ cản trở hoạt động của trình xem web Yandex. Để cho phép sử dụng iframe cho trình xem web, bạn cần viết một quy tắc riêng trong cài đặt. Ví dụ: đối với nginx, bạn có thể định cấu hình nó như thế này:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - Lỗ hổng PRSSI (Nhập biểu định kiểu tương đối đường dẫn).
Đây là một lỗ hổng trong kiểu dáng của trang web. Nó xảy ra nếu các liên kết tương đối như href="/vi/somefolder/styles.css/" được sử dụng để truy cập các tệp kiểu. Kẻ tấn công sẽ lợi dụng điều này nếu chúng tìm cách chuyển hướng người dùng đến một trang độc hại. Trang này sẽ chèn một liên kết tương đối vào url của nó và mô phỏng lệnh gọi kiểu. Bạn sẽ nhận được một yêu cầu như badsite.ru/…/somefolder/styles.css/, yêu cầu này có thể thực hiện các hành động độc hại dưới vỏ bọc của một phong cách.
Có gì nguy hiểm: Kẻ lừa đảo có thể khai thác lỗ hổng này nếu chúng tìm thấy một lỗ hổng bảo mật khác. Do đó, có thể đánh cắp dữ liệu người dùng từ cookie hoặc mã thông báo.
Những điều nhà phát triển web nên nhớ: Đặt tiêu đề X-Content-Type-Options thành: nosniff. Trong trường hợp này, trình duyệt sẽ kiểm tra loại nội dung để tìm kiểu. Nếu loại không phải là text/css, trình duyệt sẽ chặn yêu cầu.
Lỗ hổng nghiêm trọng
- Một trang có trường mật khẩu được truyền từ máy chủ qua kênh không an toàn (biểu mẫu HTML chứa (các) trường mật khẩu được cung cấp qua HTTP).
Phản hồi từ máy chủ qua kênh không được mã hóa rất dễ bị tấn công bởi “Người đứng giữa”. Kẻ tấn công có thể chặn lưu lượng truy cập và tự chèn vào giữa máy khách và máy chủ khi trang di chuyển từ máy chủ đến máy khách.
Có gì nguy hiểm: Kẻ lừa đảo sẽ có thể thay thế trang và gửi cho người dùng một biểu mẫu chứa dữ liệu bí mật, biểu mẫu này sẽ đến máy chủ của kẻ tấn công.
Những điều nhà phát triển web nên nhớ: Một số trang web gửi cho người dùng mã một lần qua email/điện thoại thay vì mật khẩu. Trong trường hợp này, lỗ hổng không quá nghiêm trọng nhưng cơ chế sẽ làm phức tạp cuộc sống của người dùng.
- Gửi biểu mẫu có thông tin đăng nhập và mật khẩu qua kênh không an toàn (Biểu mẫu đăng nhập không được gửi qua HTTPS).
Trong trường hợp này, một biểu mẫu có thông tin đăng nhập và mật khẩu sẽ được gửi từ người dùng đến máy chủ thông qua kênh không được mã hóa.
Có gì nguy hiểm: Không giống như trường hợp trước, đây đã là một lỗ hổng nghiêm trọng. Việc chặn dữ liệu nhạy cảm sẽ dễ dàng hơn vì bạn thậm chí không cần phải viết mã để thực hiện việc đó.
- Sử dụng thư viện JavaScript có lỗ hổng đã biết.
Trong quá trình quét, thư viện được sử dụng nhiều nhất là jQuery với số lượng phiên bản phong phú. Mỗi phiên bản đều có ít nhất một hoặc thậm chí nhiều lỗ hổng đã biết. Tác động có thể rất khác nhau tùy thuộc vào bản chất của lỗ hổng.
Có gì nguy hiểm: Có các cách khai thác các lỗ hổng đã biết, ví dụ:
Những điều nhà phát triển web nên nhớ: Thường xuyên quay lại chu trình: tìm kiếm các lỗ hổng đã biết - sửa chữa - kiểm tra. Nếu bạn cố tình sử dụng các thư viện cũ, chẳng hạn như để hỗ trợ các trình duyệt cũ hơn hoặc để tiết kiệm tiền, hãy tìm cơ hội khắc phục lỗ hổng đã biết. - Kịch bản chéo trang (XSS).
Cross-Site Scripting (XSS), hay cross-site scripting, là một cuộc tấn công vào ứng dụng web dẫn đến việc phần mềm độc hại được đưa vào cơ sở dữ liệu. Nếu Qualys tìm thấy một lỗ hổng như vậy, điều đó có nghĩa là kẻ tấn công tiềm năng có thể hoặc đã đưa tập lệnh js của riêng mình vào mã trang web để thực hiện các hành động độc hại.XSS được lưu trữ nguy hiểm hơn, vì tập lệnh được nhúng trên máy chủ và được thực thi mỗi khi trang bị tấn công được mở trong trình duyệt.
XSS phản ánh thực hiện dễ dàng hơn vì tập lệnh độc hại có thể được đưa vào yêu cầu HTTP. Ứng dụng sẽ nhận được yêu cầu HTTP, sẽ không xác thực dữ liệu, sẽ đóng gói và gửi ngay lập tức. Nếu kẻ tấn công chặn lưu lượng truy cập và chèn một tập lệnh như
<script>/*+что+то+плохое+*/</script>sau đó một yêu cầu độc hại sẽ được gửi thay mặt cho khách hàng.
Một ví dụ nổi bật về XSS: js sniffers mô phỏng các trang để nhập CVC, ngày hết hạn thẻ, v.v.
Những điều nhà phát triển web nên nhớ: Trong tiêu đề Chính sách bảo mật nội dung, sử dụng thuộc tính script-src để buộc trình duyệt máy khách chỉ tải xuống và thực thi mã từ một nguồn đáng tin cậy. Ví dụ: script-src 'self' chỉ đưa vào danh sách trắng tất cả các tập lệnh từ trang web của chúng tôi.
Cách tốt nhất là Mã nội tuyến: chỉ cho phép javascript nội tuyến sử dụng giá trị nội tuyến không an toàn. Giá trị này cho phép sử dụng js/css nội tuyến, nhưng không cấm đưa vào các tệp js. Kết hợp với script-src 'self', chúng tôi vô hiệu hóa việc thực thi các tập lệnh bên ngoài.Hãy nhớ ghi nhật ký mọi thứ bằng cách sử dụng report-uri và xem xét các nỗ lực triển khai nó vào trang web.
- Tiêm SQL.
Lỗ hổng cho thấy khả năng tiêm mã SQL vào một trang web truy cập trực tiếp vào cơ sở dữ liệu của trang web. Có thể chèn SQL nếu dữ liệu từ người dùng không được sàng lọc: nó không được kiểm tra tính chính xác và ngay lập tức được sử dụng trong truy vấn. Ví dụ: điều này xảy ra nếu một biểu mẫu trên trang web không kiểm tra xem dữ liệu đầu vào có khớp với loại dữ liệu hay không.Có gì nguy hiểm: Nếu kẻ tấn công nhập truy vấn SQL vào biểu mẫu này, hắn có thể làm hỏng cơ sở dữ liệu hoặc tiết lộ thông tin bí mật.
Những điều nhà phát triển web nên nhớ: Đừng tin vào những gì đến từ trình duyệt. Bạn cần tự bảo vệ mình ở cả phía máy khách và phía máy chủ.
Về phía máy khách, viết xác thực trường bằng JavaScript.
Các chức năng tích hợp sẵn trong các framework phổ biến cũng giúp thoát khỏi các ký tự đáng ngờ trên máy chủ. Bạn cũng nên sử dụng các truy vấn cơ sở dữ liệu được tham số hóa trên máy chủ.
Xác định chính xác nơi tương tác với cơ sở dữ liệu diễn ra trên ứng dụng web.
Tương tác xảy ra khi chúng tôi nhận được bất kỳ thông tin nào: yêu cầu có id (thay đổi id), tạo người dùng mới, nhận xét mới hoặc mục mới trong cơ sở dữ liệu. Đây là nơi việc tiêm SQL có thể xảy ra. Ngay cả khi chúng tôi xóa một bản ghi khỏi cơ sở dữ liệu, việc chèn SQL vẫn có thể xảy ra.
Khuyến nghị chung
Đừng phát minh lại bánh xe - hãy sử dụng các khuôn khổ đã được chứng minh. Theo quy định, các framework phổ biến sẽ an toàn hơn. Dành cho .NET - ASP.NET MVC và ASP.NET Core, cho Python - Django hoặc Flask, cho Ruby - Ruby on Rails, cho PHP - Symfony, Laravel, Yii, cho JavaScript - Node.JS-Express.js, cho Java - Mùa xuân MVC.
Theo dõi cập nhật của nhà cung cấp và cập nhật thường xuyên. Họ sẽ tìm ra một lỗ hổng, sau đó viết một bản khai thác, công khai nó và mọi thứ sẽ xảy ra lần nữa. Đăng ký nhận bản cập nhật cho các phiên bản ổn định từ nhà cung cấp phần mềm.
Kiểm tra quyền. Về phía máy chủ, hãy luôn coi mã của bạn như thể nó, từ chữ cái đầu tiên đến chữ cái cuối cùng, được viết bởi kẻ thù đáng ghét nhất của bạn, kẻ muốn phá vỡ trang web của bạn, vi phạm tính toàn vẹn của dữ liệu của bạn. Hơn nữa, đôi khi điều này là đúng.
Sử dụng bản sao, địa điểm thử nghiệm và sau đó sử dụng chúng để sản xuất. Điều này trước hết sẽ giúp tránh những sai sót, sai sót trong môi trường sản xuất: môi trường sản xuất mang lại tiền bạc, môi trường sản xuất đơn giản là rất quan trọng. Khi thêm, sửa hoặc đóng bất kỳ sự cố nào, bạn nên làm việc trong môi trường thử nghiệm, sau đó kiểm tra chức năng và các lỗ hổng được tìm thấy, sau đó lập kế hoạch làm việc với môi trường sản xuất.
Bảo vệ ứng dụng web của bạn với và tích hợp các báo cáo từ trình quét lỗ hổng với nó. Ví dụ: DataLine sử dụng Qualys và FortiWeb làm gói dịch vụ.
Nguồn: www.habr.com