1. Injection
Injection flaws occur when untrusted data sent to an interpreter through a form input or some other data submission to a web application. As part of a command or query. The attacker can easily access data without proper authentication.
Example: Attacker enter some SQL database code in the form of plaintext username. If the form input is not secured, then the SQL code will be executed. This attack is known as a SQL Injection attack.
Injection attacks can prevent data validating when a user submits it.
Validating means rejecting suspicious data and clean up the suspect data. A database admin can set controls the amount of information minimum which an injection attack can expose.
2. Broken Authentication
When an application, authenticate and manage sessions incorrectly, allowing attackers to access user accounts and the ability to compromise passwords, keys, or session tokens or to exploit other flaws. That leads to other user’s recognise temporarily or permanently disabled.
Example: Attacker can create different combinations of username or password with the list obtained during the data breach. The attacker can use a script to try to access the login screen.
Strategies to decrease authentication vulnerabilities required for active 2-factor authentication (2FA) and limiting repeated login attempts using rate limiting.
3. Sensitive Data Exposure
Protected sensitive data such as financial information, passwords stored in the web application. Attackers can give access to that data if the website is not secured. Attackers can sell these confidential data in the Dark Web.
One of the methods is known as Man-In-The-Middle-Attack.
It can minimise by encrypting all sensitive data as well as disabling the caching any confidential information. Web Applications developers can be ensured that they are not storing any confidential information/data.
Caching is the technique of storing data for future use.
Example: When a user browses a website, it will show a popup dialog box which tells to store the website cache information in the web browser. If a user revisits the site, then the browser does not have to fetch the pages from the web.
4. XML External Entities (XEE)
XEE is an attack which parses XML input in a web application. This input can be a reference to an external object which attempted to exploit a vulnerability in the parser. An ‘external object’ refers to a storage unit such as a hard drive. An XML parser misleads the sending data to the unauthorised external object, which can pass sensitive data directly to the attacker.
Prevention of XEE attack, web applications are having less involved data or at least to patch the XML parsers and disable the use of an external object in an XML application.
5. Broken Access Control
A system that controls access to information/data or performance is known as “Access Control”. It allows attackers to bypass authorisation, and they are privileged users, such as administrators.
Example: A user can change anything in web application in which they logged in without any other verification.
It can secure by ensuring that a web application uses proper authorisation tokens and set tight restrictions on them. Every privileged request that a user makes can require an authorisation token be present without having to enter their login credentials regularly.
6. Security Misconfiguration
The most common vulnerability is “System Misconfiguration”. The main reason for this vulnerability is using the default configurations or displaying excessively errors. It can reduce by removing unwanted or unused features in the application and ensuring that error messages are of used elements.
7. Cross-Site Scripting
When web applications allow the attacker to add custom code into a URL path of the website that is also seen by other users. This vulnerability can exploit to run malicious JavaScript code in the victim’s browser.
Example: Attacker can send an email to the victim who believes the user to be a trusted organisation, with a link to that organisation’s site. An email containing link could have some malicious JavaScript code at the end of the URL.
Reducing techniques for Cross-Site Scripting include ignoring untrusted HTTP requests as well as data validation in user-generated content. ReactJS and Ruby on Rails are the modern web development frameworks which provide some built-in cross-site scripting protection.
8. Insecure Deserialization
Insecure Deserialization targets many websites and web applications which all the time serialize and deserialise data. Serialisation refers to taking objects from the application source code and converting into a format which can be stored easily to a disk. Deserialisation refers to the conversion to serialised data back into objects of the application.
Serialization is like packing furniture into boxes, and deserialisation is like unpacking the boxes and assembling the furniture. An insecure deserialisation attack is like having the movers tamper with the contents of the boxes before they unpacked.
DDoS attacks and remote code execution attacks are frequent in deserialisation. The significant steps are taken to try and catch attackers, such as monitoring deserialisation and implementing type checks, the only way to protect against insecure deserialisation attacks is to prohibit the deserialisation of data from untrusted sources.
9. Using Components With Known Vulnerabilities
Libraries and frameworks are pieces of software that help developers to avoid unnecessary code and provide useful functionality.
Example: Front-end frameworks like React and smaller libraries that used to add share icons or a/b testing. Some attackers look for vulnerabilities in these components which they can then use to orchestrate attacks. Some of the more popular elements are used on hundreds of thousands of websites; an attacker finding a security hole in one of these components could leave hundreds of thousands of sites vulnerable to exploit.
Component developers often offer security patches and updates to plug up known vulnerabilities. Still, web application developers don’t always have the patched or most-recent versions of components running on their applications. To minimise the risk of running components with known vulnerabilities, developers should remove unused parts from their projects, as well as ensuring that they are receiving components from a trusted source and ensuring they are up to date.
10. Insufficient Logging And Monitoring
Developers are not serious about taking essential steps to detect data breaches in web applications. The average discovery time for a violation is around 200 days after it has happened. Attackers have much time to damage before they fix it. OWASP recommends that web developers should implement logging and monitoring as well as incident response plans to ensure that they are made aware of attacks on their applications.
