Trong blog này, chúng tôi sẽ giới thiệu về một số lỗ hổng được tìm thấy trong các ứng dụng PHP thường bị các nhà phát triển bỏ qua. Mức độ nghiêm trọng của các lỗ hổng như vậy là khá cao và có thể làm tổn hại đến toàn bộ máy chủ. Hãy giải quyết một số lỗ hổng như vậy.
SQL injection
Một cuộc tấn công SQL Injection (SQLi) khai thác việc tiêm các lệnh SQL vào các truy vấn SQL của một ứng dụng web. Một cuộc tấn công SQLi thành công cho phép người dùng độc hại truy cập và thao tác cơ sở dữ liệu phụ trợ của ứng dụng web.
Trong hình ảnh trên, người dùng độc hại có thể truy cập cơ sở dữ liệu phía sau của ứng dụng web bằng SQL tiêm. Điều này sẽ cho phép anh ta thực hiện leo thang đặc quyền ở cấp ứng dụng. Khi máy chủ SQL đang chạy trong bối cảnh quản trị hệ thống (DBO, SA), người dùng độc hại sẽ có thể sở hữu toàn bộ máy chủ.
Code Demo
#Insert statement
- Khi người dùng gửi dữ liệu qua form, giá trị company và address được lưu trong các biến cục bộ – $company và $address tìm nạp các giá trị của họ từ các biến $ _POST.
- company và address sau đó được lưu trong cơ sở dữ liệu MySQL, bảng emp sử dụng câu lệnh INSERT.
- Mysql_query kích hoạt câu lệnh INSERT.
Các mã trên là dễ bị tổn thương cho kịch bản chéo trang liên tục. Kịch bản sẽ được thực thi khi chi tiết về company và address được xem bởi người dùng hoặc quản trị viên. Điều này sẽ dẫn đến sự leo thang đặc quyền ở cấp ứng dụng, đạt được quyền cấp quản trị viên.
#Select statement
Đoạn mã trên dễ bị tấn công bởi SQL Injection vì không có biến POST nào – username và password – được lọc hoặc được sử dụng sql builder. Mã được chấp nhận một cách mù quáng bất cứ tên người dùng và mật khẩu nào. Đây là một tình huống nguy hiểm vì nó có thể thỏa hiệp ứng dụng và sau đó là toàn bộ máy chủ.
Cross-site Scripting (XSS)
Cross script scripting (XSS): Mục đích duy nhất của attacker là injection HTMLhoặc chạy JavaScript trong trang web. Mã JavaScript được đưa vào mã nguồn trang web để thực thi JavaScript trong ngữ cảnh trang web của trình duyệt.
code ở trên nhằm in một thông điệp chào mừng cho người dùng đã đăng nhập. Tên người dùng được lấy bằng biến GET. Phương thức GET lưu trữ các giá trị của các tham số chuỗi truy vấn dưới dạng các cặp được truyền qua phương thức HTTP GET.
Nhưng attacker có thể thêm các chi tiết bổ sung trong đoạn mã trên để khai thác lỗ hổng XSS. Lỗ hổng như vậy xảy ra do đầu vào của người dùng được chuyển đến một biến cục bộ do nó không được lọc bằng các bộ lọc chống xss như html specialchars… Những kiểu tấn công này có thể xảy ra khi đầu vào của người dùng được sử dụng trong đầu ra ứng dụng web cho phép kẻ tấn công kiểm soát nội dung được hiển thị cho người dùng, cuối cùng tấn công người dùng.
Ba loại XSS được xác định cho đến nay
Reflected XSS: Đây là lỗ hổng XSS phổ biến nhất. Nó xảy ra khi dữ liệu người dùng không tin cậy được gửi đến ứng dụng web và nó ngay lập tức bị dội lại dưới dạng nội dung không đáng tin cậy. Trình duyệt nhận mã từ máy chủ web và kết xuất lại.
Lỗ hổng này liên quan đến mã phía máy chủ. Hãy xem đoạn mã sau:
- Trong trường hợp này, tải trọng độc hại được thêm vào bằng cách nào đó trong yêu cầu HTTP và sau đó, nó sẽ được chèn vào trang web và được trình duyệt thực thi. Người dùng attacker lừa người dùng thực tế của ứng dụng web để nhấp vào liên kết được chế tạo đặc biệt. Bằng cách đó, tải trọng độc hại chạy vào trình duyệt trong ngữ cảnh của người dùng.
- XSS Persistent (Xss Store): Trong trường hợp này, thay vì hiển thị vector của attacker trên link thông qua GET thì nó lưu trữ trong ứng dụng web trên cơ sở dữ liệu bài viết, bình luận…. Khi nó xảy ra, nó được lặp lại cho tất cả người dùng ứng dụng web mà không cần người dùng click vào các link được gắn các vector tấn công xss.
- XSS dựa trên DOM: Hai loại trên chỉ tồn tại trong code phía máy chủ và đầu vào của người dùng phải được gửi đến máy chủ để xử lý. Nhưng XSS dựa trên DOM chỉ tồn tại trong mã phía máy khách, điển hình là JavaScript. Chúng ta hãy xem các đoạn mã dưới đây dễ bị tổn thương với XSS. Điều này tương tự như XSS được phản ánh nhưng nó không bao giờ tương tác với phía máy chủ.
Đoạn mã trên rõ ràng dễ bị tổn thương đối với kịch bản xss DOM. Trong trường hợp này, mã phía máy khách có thể truy cập các phần tử DOM của trình duyệt. Nó chủ yếu tác động đến lịch sử, cookie và lưu trữ cục bộ.
Tác động của các lỗ hổng XSS:
- Mạo danh người dùng để thực hiện một số hành động nhất định thay mặt người dùng dẫn đến người dùng độc hại có được các đặc quyền cao hơn trong ứng dụng web – điển hình là một cuộc tấn công CSRF.
- Người dùng độc hại có thể đọc dữ liệu mà chỉ người dùng được xác thực mới có thể truy cập.
- Injection phần mềm độc hại vào trang web có thể mang lại lợi ích cho attacker trong việc truy cập từ xa vào máy tính của khách truy cập trang web.
Xử lý các lỗ hổng XSS
Kích hoạt một số tiêu đề bảo vệ có thể ngăn XSS đến một mức nhất định
X-XSS-Protection Header:
header này được thiết kế để cho phép bộ lọc cú pháp xss được tích hợp trong các trình duyệt hiện đại. Khi phát hiện một cuộc tấn công kịch bản xss có sẵn, trình duyệt sẽ tự clean trang để ngăn chặn cuộc tấn công.
Khi được đặt thành x-xss-Protection: 1 – cho phép bộ lọc XSS
Khi mode = block được đặt cùng với nó, thì trình duyệt sẽ dừng hiển thị trang khi phát hiện tấn công XSS.
Apache
Nginx
IIS:
thêm đoạn code sau vào web.config
Mã hóa đầu ra của người dùng:
Chúng ta hãy giả sử rằng người dùng đang tìm kiếm một sản phẩm cụ thể trên trang web Thương mại điện tử. Ứng dụng web không bao giờ nên tin tưởng đầu vào của người dùng và phải mã hóa đầu vào của người dùng trước khi nó được hiển thị dưới dạng đầu ra trên trang web. Trước khi thêm bất kỳ dữ liệu nào trong phần tử HTML hoặc thuộc tính, nhà phát triển phải đảm bảo rằng nó được mã hóa HTML. Điều này sẽ mã hóa các ký tự đặc biệt như < >
Nhìn chung, việc sử dụng iframe phải được tránh trên ứng dụng web của bạn, người dùng độc hại có thể sử dụng để nhúng nội dung ẩn khỏi các trang web khác. Điều này ảnh hưởng đến mọi khách truy cập ứng dụng web của bạn bởi phần mềm độc hại hoặc các lỗ hổng khác như CSRF (giả mạo yêu cầu phía khách hàng). Nó lừa người dùng thực thi các hành động không mong muốn trên ứng dụng web mà họ được xác thực. Mục đích của các cuộc tấn công như vậy là để thay đổi dữ liệu trong cơ sở dữ liệu.
Local File Inclusion
Về cơ bản, một tệp PHP có thể được bao gồm trong một tệp PHP khác bằng cách sử dụng hàm include (). Nội dung của các tệp được bao gồm trong tệp PHP đang gọi cùng với bất kỳ hàm hoặc biến nào được khai báo trong tệp PHP đó. Ví dụ: một tệp có tên config.php chứa chi tiết kết nối MySQL và một biến liên kết được sử dụng để kết nối và tìm nạp dữ liệu từ máy chủ MySQL khi thực hiện các câu lệnh SQL. Nhà phát triển sẽ đưa tệp này vào tệp index.php để lấy dữ liệu từ máy chủ MySQL.
Kịch bản đầu tiên:
Chúng ta hãy giả sử rằng có một biến GET tên sản phẩm và tên được chuyển đến biến cục bộ:
Bây giờ vì biến $pagepage không được lọc, attacker giờ đây có thể đọc bất kỳ nội dung tệp nào từ máy chủ web. Mã này cũng dễ bị tổn thương khi đưa vào tập tin từ xa.
Kịch bản thứ hai:
file_get_contents(include/language/$language.lang.php)
Đoạn mã trên dễ bị tổn thương nhưng cũng dẫn đến việc thực thi mã từ xa.
Attacker có thể truy cập /proc/self/environ thông qua LFI, thì việc thực thi mã từ xa là có thể bằng cách sử dụng giá trị user-agent người dùng
Nó có thể thực thi bất cứ thứ gì trên máy chủ của bạn mà php có thể làm được
Kịch bản thứ ba:
file_get_contents(include/language/$language.lang.php)
Mã được đề cập ở trên vẫn dễ tấn công file inclusion, nhưng nó sẽ đọc nội dung của tệp. Nó không cho phép thực thi mã từ xa.
Cho đến nay, người ta xác định rằng bao gồm mọi giá trị tham số GET / POST không được lọc hoặc giới hạn trực tiếp trong hàm bao gồm đều nguy hiểm và có thể dẫn đến các lỗ hổng rủi ro cao.
Một số giải pháp:
SQL Injection, XSS và LFI là các lỗ hổng xác thực đầu vào và có thể được ngăn chặn bằng cách thực thi lọc, chặn, giới hạn … đầu vào trên bất kỳ tham số nào do người dùng kiểm soát. Ý tưởng là không bao giờ tin tưởng đầu vào của người dùng và thực hiện các biện pháp cần thiết trong mã để đảm bảo rằng chỉ có dữ liệu dự định được truyền cho các biến cục bộ.
Triển khai Mod_Security (Modsec): Đây là Tường lửa ứng dụng Windows nguồn mở (WAF) được phát triển bởi Trustwave Spiderlabs. Nó bổ sung thêm một lớp bảo mật để bảo vệ các ứng dụng web và có sẵn cho Linux, Windows, Solaris, FreeBSD, Mac OS X. Nó tích hợp tốt với máy chủ HTTP HTTP, máy chủ IIS và máy chủ Nginx. Mod_Security được cấu hình là máy chủ proxy giữa người dùng, máy chủ web và dựa trên các quy tắc do người dùng xác định. Nó giám sát và lọc bất kỳ dữ liệu đến và đi từ máy chủ web không đáp ứng các quy tắc được xác định trong đó. Nó chặn bất kỳ ký tự đặc biệt nào được chuyển đến các biến GET hoặc POST để loại trừ SQL Injection
Thực hiện chức năng PHP mysql_real_escape_opes.
Một cách khác là tạo một hàm để lọc các ký tự đặc biệt chuyển đến các biến GET / POST.
4. Xác thực các form đầu vào – Người dùng chỉ được phép nhập thông tin dự định vào form nhập. Ví dụ: form văn bản tên đầu tiên chỉ nên là các ký tự chữ và số. Hộp văn bản chỉ nên chấp nhận giá trị số để chấp nhận số điện thoại di động. Hãy xem xét ví dụ dưới đây:
