Website Penetration Testing – Richard Callaby

OS Command Injection – What is it?

OS Command Injection is a type of security vulnerability that occurs when an attacker is able to execute arbitrary system commands on a target machine through a vulnerability in a web application. This type of attack is often seen in web applications that use system calls, system commands, or shell commands to perform various tasks. Attackers take advantage of these vulnerabilities to execute arbitrary code on the target machine, which can result in a variety of security incidents, such as data theft, data corruption, or complete system compromise.

OS Command Injection attacks are typically carried out by manipulating the input data of a web application to include malicious code. For example, if a web application requires a user to input a file name for a file upload operation, an attacker could manipulate the input to include malicious code. If the web application uses the input directly in a system call or shell command without proper validation or sanitation, the attacker’s code will be executed on the target machine.

OS Command Injection attacks can also be carried out by manipulating the parameters of a URL. For example, if a web application provides a URL that is used to execute a system command or shell script, an attacker could manipulate the URL to include malicious code. If the web application uses the URL directly in a system call or shell command without proper validation or sanitation, the attacker’s code will be executed on the target machine.

There are several ways to protect against OS Command Injection attacks. The first step is to validate all user input to ensure that it only contains acceptable characters. This can be accomplished by using regular expressions to match acceptable input patterns and reject input that does not match the pattern. For example, you could use a regular expression to only allow alphanumeric characters in file names or URL parameters.

Another way to protect against OS Command Injection attacks is to use a safe API for system calls or shell commands. Safe APIs provide a layer of abstraction between the web application and the underlying system, and they ensure that only valid input is passed to the system. This can prevent attackers from injecting malicious code into system calls or shell commands.

It is also important to sanitize all user input before using it in a system call or shell command. This can be accomplished by removing or escaping special characters that could be used to inject malicious code. For example, you could remove any instances of the semicolon (;) or pipe (|) characters, which are often used in OS Command Injection attacks.

Another important step in protecting against OS Command Injection attacks is to keep your web application and operating system up to date with the latest security patches. This will help to prevent vulnerabilities in your web application from being exploited by attackers.

OS Command Injection is a serious security vulnerability that can result in the compromise of a target machine. To protect against this type of attack, it is important to validate all user input, use a safe API for system calls or shell commands, sanitize user input, and keep your web application and operating system up to date with the latest security patches. By following these best practices, you can help to secure your web application against OS Command Injection attacks and keep your sensitive data safe.

Insecure Direct Object References or IDOR Explained

Insecure Direct Object References (IDORs) are a common vulnerability in web applications, often resulting from a lack of proper access controls. They occur when a web application allows a user to access resources or perform actions for which they should not have authorization.

This vulnerability can be exploited by malicious actors to gain unauthorized access to sensitive information, manipulate data, or perform other malicious actions. As such, IDORs are a prime target for penetration testers, who use a variety of techniques to identify and exploit these weaknesses.

In a typical scenario, an IDOR vulnerability occurs when a web application uses direct object references, such as URLs or form parameters, to access resources such as database records or files. For example, consider a web application that allows users to view their own personal information, such as name, address, and phone number. The application might use a URL like this to retrieve the user’s information:

www.example.com/userinfo?id=123

In this case, the “id” parameter specifies the user’s ID, and the application retrieves the information for that user from the database. If the application does not properly validate the “id” parameter, it is possible for a malicious user to modify the URL to access information for another user, for example:

www.example.com/userinfo?id=456

If the application does not properly validate the “id” parameter, the malicious user can access the information for user 456, even if they are not authorized to do so. This is the essence of an IDOR vulnerability.

Penetration testers use a variety of techniques to identify and exploit IDORs, including manual testing, automated scanning, and exploiting known vulnerabilities. For example, a manual tester might try modifying URL parameters, form inputs, and other requests to see if they can access unauthorized resources or perform unauthorized actions. Automated scanning tools, such as web application vulnerability scanners, can be used to identify IDORs by automatically generating and sending thousands of requests to the application, looking for unexpected responses.

Finally, exploiting known vulnerabilities is a common method for finding IDORs. For example, if a tester is aware of a specific type of IDOR vulnerability, such as a vulnerability in a particular framework or library, they may be able to write an exploit to take advantage of that vulnerability.

Once an IDOR vulnerability has been identified, the next step is to exploit it. This typically involves crafting a request that triggers the vulnerability, allowing the tester to access or manipulate sensitive information or perform other unauthorized actions. Depending on the specific vulnerability, the tester may be able to access sensitive information, manipulate data, or perform other malicious actions.

It is important to note that IDORs are a common vulnerability, and the consequences of an IDOR exploit can be serious. For example, a malicious user could access sensitive information, such as medical records, financial information, or personal information, and use that information for identity theft, fraud, or other malicious purposes.

IDORs are a common vulnerability in web applications, and a prime target for penetration testers. By identifying and exploiting these vulnerabilities, testers can help organizations identify weaknesses in their applications and take steps to secure them. With proper security controls in place, organizations can reduce the risk of IDOR exploits and protect sensitive information from malicious actors.

SSRF or Server Side Request Forgery Explained

Server Side Request Forgery (SSRF) is a security vulnerability that can be found in web applications. It is a type of attack where the attacker can manipulate the server-side component of a web application to send requests to internal systems that would not be normally accessible from the outside. This can result in sensitive information being disclosed or allow an attacker to gain access to internal systems.

In SSRF attacks, the attacker sends specially crafted requests to the web application, which then sends additional requests to other systems on behalf of the attacker. This can allow the attacker to bypass firewalls, access restricted systems, and obtain sensitive information such as internal IP addresses, system details, and database credentials.

One common example of SSRF is when a web application accepts user-supplied URLs as input and then retrieves the contents of those URLs. If the web application does not properly validate the input, an attacker could manipulate the URL to send a request to an internal system instead of the intended external website. This can allow the attacker to access sensitive information or even gain access to the internal network.

Another example of SSRF is when a web application integrates with a payment gateway that requires a callback URL. If the web application does not properly validate the callback URL, an attacker could manipulate the URL to send a request to an internal system instead of the payment gateway. This can result in sensitive information being disclosed or the attacker being able to make unauthorized transactions.

In order to prevent SSRF attacks, web application developers should implement proper input validation and sanitization, and limit the systems that the web application can make requests. This can be done by only allowing requests to specific domains or IP addresses, or by implementing authentication and authorization mechanisms for internal systems. Additionally, security teams should regularly test web applications for SSRF vulnerabilities as part of their penetration testing efforts.

SSRF can have serious consequences for organizations if left unmitigated. The disclosure of sensitive information can result in a data breach, and the attacker’s ability to access internal systems can lead to further compromise of the organization’s network. As a result, it is important for organizations to take steps to prevent SSRF attacks and regularly test their web applications for vulnerabilities.

Server Side Request Forgery is a critical security vulnerability that can result in the disclosure of sensitive information and access to internal systems. Web application developers should implement proper input validation and sanitization, and limit the systems that the web application can make requests to. Security teams should also regularly test web applications for SSRF vulnerabilities as part of their penetration testing efforts to ensure the security of their systems.