Out of the broad ranged complex applications that the world-wide-web can cater to, as a huge and sophisticated platform, some are developed in rather short turn-around-times. These applications undergo speedy phases of development, thus, eliminating any possibility for security risk management.
So, we decided to assess and address to all the possible security risks for web applications in this post. The assessment helps the developers identify poor coding practices that leave the applications at the risk of attacks such as cross-site scripting and SQL injections. Here are 10 potential application security risks that you ought to protect your application against:
1) Injection
It is the risk surfacing on sending any untrusted data to an interpreter such as SQL or LDAP as a part of a command or a query. In this case, the attacker can potentially trick the interpreter into unauthorized access to data and execution of unwanted commands. A grave security risk, injection can result into lost or corrupted data, denied access or loss of accountability. It is recommended to use the MVC frameworks, conduct validation of inputs, escape special characters as a part of inputs validation and make use of parametrized APIs for form integration in order to help prevent injection.
2) Broken Authentication and Session Management
Broken authentication and session management results from improper implementation of application authentication practices and poor session management methods. This can result in compromised user or system administration accounts. This allows the attackers to get hold of passwords, keys or session tokens and exploit the application or steal identities. This usually leads to a bigger risk of the attacker accessing some or all the accounts on the platform with the privileged accounts as the usual target. By appropriately encrypting the user id credentials, using strong passwords, URL rewriting, implementing proper session management methods and using encrypted connections this risk can be prevented.
3) Cross Site Scripting XSS
The risk of cross-site scripting is encountered when an application incorporates user supplied data into a page sent to the browser without appropriately escaping or validating the content. As a result, the attacker is in a position to execute scripts in the client’s browser enabling them to hijack user sessions, deface web sites, insert hostile content or redirect the user to malicious sites. This risk can be prevented by properly escaping all the untrusted content, sanitizing data inputs and with the help of the other content security policies built into the applications code.
4) Insecure Direct Object References
The risk of insecure Direct Object References, arises from a developer exposing a reference to an internal implementation object (such as a file or a directory or database key) without an access control check. This gives the attackers an opportunity to exploit these references to gain unauthorized access to data. Software testers can easily manipulate with the application parameter values to detect such flaws. This risk can be effectively prevented by selecting a specific approach to protect each user’s accessible object.
5) Security Misconfiguration
Security Misconfiguration can happen due to a number of reasons including a misconfigured web application, API authentication, server configuration or database configuration and this can expose the application to malicious attacks or vulnerabilities. Attacker gains unauthorized access to the system by getting hold of the default accounts, unpatched flaws, unprotected files and directories. This can result in a complete system compromise which needs to be secured by the developers and system administrators who work to ensure that security patches are applied and no known vulnerabilities are detected. This risk can be prevented against, by server hardening, strong application architecture and frequent security audits.
6) Sensitive Data Exposure
Sensitive Data Exposure happens when the web applications do not properly protect sensitive data, such as credit cards, tax IDs, and user authentication credentials. This results in the attackers stealing or manipulating the weakly protected data to conduct credit card fraud, identity theft, or other such crimes. Sensitive data deserves additional protection such as encryption at the database level or while in-transit. Also, special precautions need to be taken while exchanging it with the browsers. The threat of sensitive data exposure can be best prevented against, by using encryption of storing sensitive data, SSL certificates for the web site, ensuring the use of strong encryption algorithms and safe keys for APIs, disabling autocomplete and caching of sensitive data parameters.
7) Missing Function Level Access Control
A majority of web applications verify function level access rights before making that functionality visible in the UI. However, at the time of accessing each function, the applications need to perform these access control checks on the server too. In case of a non-verification of the request, the attackers can forge requests to gain unauthorized access to the functionality.
8) Cross Site Request Forgery
In case of CSRF, the attacker forces the client’s browser to send a forged HTTP request, with the session cookies and other automatically included authentication information. This forged HTTP request is sent to a vulnerable web application. The vulnerable application allows the attacker to forcefully generate requests from the victim’s browser, that the app accepts considering them as legitimate requests from the client.
Detecting the risk of CSRF is fairly easy using penetration testing or code analysis. It can be prevented to a large extent by including a unique token in a hidden field. This sends the value in the body of the HTTP request and prevents its inclusion in the URL, which is more prone to exposure. Requiring the user to re-authenticate, or prove they are a user (e.g., using a CAPTCHA) can also protect against CSRF.
9) Using Known Vulnerable Components
Components, such as libraries, frameworks, and other plugins have full privileges on the application source code. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. The best protection against these is to update the components and plugins on a regular basis and determine security update policies for these.
10) Unvalidated Directs and Forwards
Unvalidated directs and forwards let the attackers redirect victims to phishing or malware sites, or use forwards to access unauthorized pages. Unsafe forwards may allow access control bypass. The best prevention against these is to avoid using redirects and forwards in your codebase. It is recommended that any such destination parameter is coded as a mapping value, rather than the actual URL or portion of the URL so that the server side code translates this mapping to the target URL.
Comment or Contact us in case of any query.
English 
العربية 
