The article explains about the several common vulnerabilities in web applications and a detailed explanation about their risks, causes and recommendations.
Remote File Inclusion (RFI):
Remote File Inclusion (RFI) vulnerability occurs when a web application inputs a path to a file for a web page that includes dynamically reference external scripts. It allows an attacker to insert remotely hosted files along with a script on the web server.
Remote File Inclusion is mostly used for packaging common code into different files that are later cited by main application modules.
This vulnerability is basically due to a lack of proper input validation, that permits the user’s input (URL, parameter value, etc.) to proceed to the “file include” commands. The attacker can trick the web application to include remote files with malicious code that will run on the server.
Potential web security risks of a successful RFI attack include sensitive information disclosure, compromised servers, Cross-site Scripting (XSS), and execution of arbitrary code that leads to full system compromise.
Recommendations:
- Proper validation and sanitization of all user input.
- Whitelist the files that are allowed to be included in the application.
- Disable the remote file inclusion in coding level configuration, if it’s completely not required.
- Apply output validation mechanisms on the server end too.
Local File Inclusion (LFI):
Local File Inclusion (LFI) vulnerability occurs when a web application exposes and runs files on the web browser without properly sanitizing the input. This LFI flaw can allow an attacker to alter the input and inject path traversal characters and insert other files from the web server.
Local file inclusion (LFI) attack is almost the same as remote file inclusion attack except instead of including remote files, only local files are included for execution.
The security consequences for this LFI vulnerability lead to remote code execution, information disclosure, database access, Cross-Site Scripting, and executing arbitrary commands.
This vulnerability can be more dangerous when an attacker is permitted to read or execute files on the victim machine and if the server is misconfigured and is running with high privileges, the attacker can gain access to sensitive information and exploit the system and server.
Recommendations:
- Proper validation and sanitization of all user input.
- Whitelist the files that are allowed to be included in the application.
- Avoid including files on a web server that can be compromised, use a database instead.
- Maintain specific limits to the API so that only inclusion from directories under it work so that Directory Traversal attack could not take place in this situation.
Insecure HTTP Methods:
If some of the HTTP methods that are insecure such as DELETE, TRACE, PUT, OPTIONS, etc, are permitted in the web server, the attacker can perform malicious actions and gain access to the system which affects the environment and its users.
For example, DELETE method can delete the application content or deny the service.
TRACE method can permit cross-site tracking attacks.
PUT method can allow an attacker to upload malicious files on the web server.
Recommendations:
- Allow only GET and POST methods for all HTTP requests on the web server and enable limited methods that are required for the application.
- If there is a requirement of Insecure HTTP methods on the web server, perform proper authorization and restrict only for particular resources.
Missing Secure Headers:
HTTP security headers are a subset of HTTP headers that are used to interchange between a web client and a server to define the security related details of HTTP communication.
The risk factor is that if the secure headers are missing, the attacker can perform attacks like Cross-Site Scripting, clickjacking, code injection, MIME types, etc.
Recommendations:
Implementation of HTTP secure headers provides an extra layer of security by restricting malicious attacks and strengthening web application security.
Below are the most recommended HTTP security headers:
- HTTP Strict Transport Security (HSTS): Allow the web server to use encrypted HTTPS connections instead of plain-text HTTP communication.
- Content Secure Policy: Allows to control permitted sources and other parameters in the web application that prevent attacks such as CSS and other code injections.
- XSS-Protection Header: Used to defend Javascript injection attacks through cross-site scripting.
- X-Frame-Options: Disallowed to the page embedded into another page within the iframe to load through clickjacking attack.
- X-Content-Type-Options: Restricts the browser from interpreting files as a different MIME type to what is specified in the Content-Type HTTP header.
- Cross-Origin-Resource-Policy (CORP): enables controlled access and restricts cross-origin or cross-site embedding of the returned resources.
Improper Error Handling:
Improper Error Handling vulnerability occurs when an internal error message is displayed with detailed information to an end-user that is not authorized. The error messages such as database dumps, stack traces, network timeouts, error codes, functioning of the application or website, etc, which reveal sensitive information of the application and such details that can help the attacker to manipulate and exploit the application.
For example, if there is an error message which contains the structure of a SQL database table information, this is enough for an attacker to carry out a successful SQL injection attack and in worst scenarios can directly expose sensitive data like passwords and other credentials.
This vulnerability generally occurs in an application when an error message is not handled in a secure manner at the coding level itself such as not testing for errors, catching but not handling errors.
Recommendations:
- The first important step to secure from improper error handling flaws is finding and replacing these errors with a more secure approach.
- Programmers must perform a complete code review of error handling logic in their system and ensure proper error handling all over.
- Specific policy should be implemented and documented for the error handling, that includes the type of errors to be handled, and limited information should be displayed back to the user in the error message.
- Specific classes of error should be logged that assist to find implementation flaws in the application or hacking attempts.
Previous Page —————————————————————————————————— Next Page
Found this article interesting? Follow DefenseLead on Twitter, Facebook and LinkedIn to read more exclusive content.