Hướng dẫn what are the types of vulnerabilities encounter when writing a php code? - Các loại lỗ hổng gặp phải khi viết mã php là gì?

Besides brute-force attacks that try to guess your password by simply using the login screen, bots that try to exploit vulnerabilities in your website PHP code are the most common form of attack targeting WordPress websites. Most of your time securing your site will be spent securing vulnerabilities in your website PHP code. When you upgrade WordPress core to protect against a new kind of attack, you are upgrading to prevent an attack on WordPress’s PHP code. The same applies when you upgrade your themes and plugins to patch a vulnerability.

PHP is the code that runs your WordPress website. Your plugins, themes and any other applications installed on your website like phpmyadmin also include PHP code.

Vulnerabilities in PHP code are usually caused by a mistake that a developer made when writing the original code. It is quite common for a developer to launch a perfectly working PHP application like WordPress, but to not anticipate all the ways that hackers on the internet will try to gain access. As the application is used more and more, the developer will learn from users and their experiences with attacks how the website can be made more secure. Developing a PHP application is an evolutionary process, which is why it is important to keep abreast of security alerts.

You will notice that most of the vulnerabilities below are caused by ‘unsanitized’ user input. That is, input from a user that the web application accepts but contains malicious code or is passed to a part of the application in a way that creates a vulnerability. That is why, when creating PHP applications or analyzing them, it is important to focus on all areas where user input is received and ensure that user input is treated correctly.

Vulnerabilities in PHP are generally grouped into categories based on their type. Below is a list of the most common kinds of vulnerabilities in PHP code and a basic explanation of each. This document will not include example PHP code because it is written for a non-developer audience.

Remote Code Execution or RCE

Remote Code Execution (RCE) occurs when an attacker is able to upload code to your website and execute it. A bug in a PHP application may accept user input and evaluate it as PHP code. This could, for example, allow an attacker to tell the website to create a new file containing code that grants the attacker full access to your website. When an attacker sends code to your web application and it is executed, granting the attacker access, they have exploited an RCE vulnerability.

This is a very serious vulnerability because it is usually easy to exploit and grants full access to an attacker immediately after being exploited.

SQL Injection or SQLi

SQL Injection occurs when an attacker is able to send their own instructions to your database and the database executes those instructions. This occurs when a PHP developer has taken input from a website visitor and passed it to the database without checking to see if it contains anything malicious or bothering to clean out any malicious code.

SQL Injection can allow an attacker to access all of your website data. They can also create new data in your database which may include links to malicious or spam websites. An attacker may also be able to use SQL Injection to create a new administrative level user account which they can then use to sign-into your website and gain full access.

SQLi is a serious vulnerability because it is easy to exploit and often grants full access immediately.

Cross-Site Scripting or XSS

Cross-Site Scripting (XSS) occurs when an attacker causes malicious code to load in a website visitor’s browser and execute. This code can then perform malicious actions like stealing user cookies, which can grant administrative level access, or performing functions as the user which can grant additional access.

There are two kinds of XSS: Stored XSS and Reflected XSS. A Stored XSS vulnerability occurs when an attacker is able to get the website to store malicious code which is later served up inside another user’s browser and executed. An example of stored XSS is where an attacker posts a comment on your WordPress website that contains code that steals user cookies and sends them somewhere.

Reflected XSS occurs when an attacker creates a link that contains malicious code. If the link is loaded in a browser, the website then serves up the malicious code as part of the website content. This code then executes in a user’s browser and can steal cookies or perform other malicious tasks. An example of a Reflected XSS is a WordPress search results page where the search query is included in the URL and is not sanitized correctly. The page then serves up the search results along with whatever the original query was. This could be malicious code that executes inside a visitor’s browser. If you wanted to exploit a website using Reflected XSS, you could create a link to a search results page that contains malicious code and send that to the site admin which would then steal his or her cookies.

Yêu cầu trang web giả mạo hoặc CSRF

Sự giả mạo yêu cầu chéo (CSRF) xảy ra khi kẻ tấn công có thể tạo liên kết và nhận quản trị viên trang web hoặc ai đó có quyền truy cập đặc quyền để nhấp vào liên kết đó khiến trang web thực hiện hành động. Ví dụ: nếu kẻ tấn công có thể tạo một liên kết, khi được nhấp vào bởi một quản trị viên trang web, đã tạo một người dùng ’quản trị viên mới với mật khẩu đã biết, đó sẽ là một cuộc tấn công của CSRF. Kẻ tấn công sau đó chỉ đơn giản là phải tìm cách đánh lừa quản trị viên trang web nhấp vào liên kết đó để tạo người dùng quản trị viên mới với mật khẩu mà họ biết.

WordPress có một cách thông minh để bảo vệ chống lại loại tấn công này bằng cách sử dụng một thứ gọi là ’nonce. Đây là mã thông báo bảo mật (chỉ đơn giản là một số) mà quản trị viên được cấp mỗi khi họ đăng nhập. Mỗi khi một quản trị viên trang web trên WordPress thực hiện một cái gì đó nhạy cảm, trình duyệt của họ bao gồm một ’nonce. Nếu kẻ tấn công cố gắng tạo một liên kết để sử dụng trong một cuộc tấn công CSRF, họ cũng sẽ phải biết ’nonce để gửi với liên kết đó. Người không thay đổi hàng ngày, đánh bại các cuộc tấn công CSRF.

Tuy nhiên, đôi khi bạn sẽ thấy một plugin hoặc nhà phát triển chủ đề WordPress không sử dụng không sử dụng để xác minh các yêu cầu và điều này đưa các lỗ hổng CSRF vào sản phẩm của họ. Để khắc phục điều này, nhà phát triển sẽ chỉ cần thêm mã sử dụng khả năng không được tích hợp WordPress WordPress để xác minh các yêu cầu.

Xác thực Bypass

Đôi khi, một nhà phát triển PHP sẽ nghĩ rằng họ xác nhận chính xác rằng khách truy cập trang web có mức truy cập chính xác trước khi thực hiện một hành động, nhưng thực tế họ đang kiểm tra sai.

Một cách mà lỗi này tập trung vào các ứng dụng WordPress là thông qua một lỗi phổ biến mà các nhà phát triển WordPress thực hiện nơi họ sử dụng một hàm gọi là ‘is_admin (), để cố gắng xác thực rằng ai đó là quản trị viên. Hàm này thực sự được thiết kế để cho bạn biết nếu ai đó đang xem trang quản trị viên và nó không xác nhận rằng khách truy cập trang web thực sự là một quản trị viên. Nếu một nhà phát triển mắc lỗi này, họ có thể cấp cho người dùng không phải người dùng quyền truy cập vào các tính năng mà chỉ có quản trị viên có quyền truy cập. Đây là một lỗ hổng xác thực.viewing an admin page and it does not validate that a site visitor is actually an administrator. If a developer makes this mistake, they can grant non-admin users access to features that only administrators have access to. This is an authentication bypass vulnerability.

Có một số cách khác để đưa xác thực bỏ qua các lỗ hổng vào các ứng dụng và nói chung chúng được tạo khi nhà phát triển không kiểm tra chính xác người dùng có truy cập trước khi thực thi chức năng không.

Tiêm đối tượng PHP

Đây là một cuộc tấn công phức tạp hơn xảy ra khi ứng dụng PHP lấy đầu vào của người dùng và chuyển nó đến một hàm gọi là ‘unserialize (), lấy một đối tượng được lưu trữ và biến nó thành một đối tượng trong bộ nhớ. Điều này nghe có vẻ phức tạp nhưng điều quan trọng cần lưu ý ở đây là một lần nữa, nó xảy ra khi nhà phát triển cho phép đầu vào của người dùng được sử dụng một cách không an toàn trong ứng dụng PHP.

Bao gồm tệp từ xa (RFI) và bao gồm tệp cục bộ (LFI)

Bao gồm tệp từ xa hoặc RFI xảy ra khi ứng dụng PHP lấy đầu vào của người dùng và chuyển nó đến một hàm được thiết kế để tải tệp. Nếu tệp này là URL, hàm có thể & nbsp; tải mã PHP từ một trang web khác mà kẻ tấn công chỉ định sau đó sẽ được thực thi trên trang web của bạn. Việc bao gồm một tệp từ xa trong URL được gọi là bao gồm tệp từ xa hoặc RFI.

Nếu tệp mà kẻ tấn công truyền là một tệp cục bộ, ứng dụng có thể xuất nội dung của tệp đó vào màn hình. Đây thường là cách một kẻ tấn công có được quyền truy cập vào một trang web WordPress WP WP-config.php. Điều này được gọi là bao gồm tệp cục bộ hoặc LFI.

Các chức năng có thể dễ bị RFI và LFI trong PHP là: bao gồm, bao gồm_once, fopen, file_get_contents, yêu cầu và yêu cầu_once.

Tất cả các chức năng này tải mã PHP hoặc nội dung từ một nguồn mà nhà phát triển chỉ định. Nếu cài đặt PHP trên trang web được cấu hình không an toàn, kẻ tấn công có thể tải một tệp nhạy cảm dưới dạng mã PHP hoặc nội dung hoặc một tệp từ xa cho phép họ truy cập vào & NBSP; Trang web của bạn.

Hầu hết các cài đặt PHP hiện đại đều bảo vệ chống lại các cuộc tấn công RFI tải URL từ xa bằng cách giới hạn nơi có thể bao gồm các tệp. Tuy nhiên, việc các nhà phát triển PHP vô tình viết mã cho phép kẻ tấn công có quyền truy cập vào một tệp cục bộ như WP-config.php là khá phổ biến. Vì lý do này, các lỗ hổng bao gồm tệp từ xa là rất hiếm ngày nay, trong khi các lỗ hổng bao gồm tệp cục bộ là khá phổ biến.

Sự kết luận

Tài liệu này đã cho bạn sự hiểu biết về các loại lỗ hổng PHP phổ biến nhất và cách chúng được tạo ra. Là một quản trị viên có trách nhiệm WordPress, bạn sẽ theo dõi danh sách gửi thư bảo mật và sẽ được cảnh báo về các lỗ hổng mới khi chúng xuất hiện. Hầu hết các lỗ hổng bạn sẽ thấy sẽ là một trong những loại trên. Với kiến ​​thức mới mà bạn có được, bạn sẽ hiểu rõ hơn về mức độ nghiêm trọng của những lỗ hổng này, bạn sẽ được trang bị tốt hơn để đặt câu hỏi cho các nhà phát triển về lỗ hổng và bạn sẽ có kiến ​​thức tốt về cách khai thác lỗ hổng trên trang web của riêng bạn trước khi bạn vá nó.

Các lỗ hổng của PHP là gì?

6 loại lỗ hổng là gì?

Các loại lỗ hổng khác nhau là gì?

Tại sao PHP có rất nhiều lỗ hổng?