Table of Contents
- Database Injection
- Broken Authentication
- Sensitive Data Exposure
- XML External Entities (XEE)
- Broken Access Control
- Security Misconfiguration
- Cross-site Scripting (XSS)
- Insecure Deserialization
- Using Components with Known Vulnerabilities
- Insufficient Logging and Monitoring
Database Injection:
In case of sending untrusted pieces of data to the interpreter as a part of command through any area that takes user input i.e form input or any other data submission area, injection flaws occur. The attacker’s malicious queries can trick the interpreter into executing commands that can show up confidential data that the user has no authorization to have a look at. For example in an SQL injection attack, when the form input is not properly sanitized, the attacker can enter the SQL database and access its contents without authorization, just by entering malicious SQL database code in a form that is expecting a plaintext. Any type of field that takes the user’s input is injectable i.e parameters, environment variables, all web services, etc.
The application is vulnerable to the injection attack when user-supplied data is not sanitized and validated, by the use of dynamic queries without context-aware escaping and the use of hostile data directly. Injection flaws can easily be discovered through the examination of code and by the use of automated tools like scanners and fuzzers. To prevent injection attacks, there is some measure that can be taken like separating the data from commands and queries, use of a safe API that provides a parameterized interface, use of “white-list” server-side input validation through tools like Snort, escaping of special characters using specific escape syntax, etc.
An injection attack can lead to a massive data loss, disclosure of confidential information, denial of access and it can even lead to a complete application takeover. Some SQL controls like LIMIT can be used to control huge amounts of data loss in case of an attack. Some types of injection attacks are SQL, OS, NoSQL, LDAP injection attacks.
Broken authentication:
Attackers can access user accounts and can even compromise the whole host system through admin accounts, using the vulnerabilities in authentication systems. Authentication flaws allow the attacker to compromise passwords, session tokens, authentication keys and can be chained with other attacks that can lead to unauthorized access of any other user account or session temporarily and in some cases, permanently. Let’s say a user has a wordlist or a dictionary of millions of valid user names and passwords obtained during a breach. He can use them one by one in an extremely less time using automated tools and scripts on the login system to see if anyone does work. Poor implementation of identity management and access controls leads to vulnerabilities like broken authentication.
The application is vulnerable to authentication attack when it permits trying of different usernames and passwords, permits dictionary attacks or brute force attacks without any defense strategy, use easy, default passwords or passwords that are leaked in any breach, exposes session ids in URL, uses poor password recovering scheme, uses a pattern of cookies. Broken authentication can be exploited easily using simple tools for brute-forcing and dictionary attacks with a good dictionary. These types of attacks can be prevented using multi-factor authentication systems, by implementing weak password checks by running a password through a bad passwords’ database, by not using default credentials, by aligning password complexity policy, by the use of good server-side session manager which generates a new random session-id after login, etc.
Broken authentication vulnerability can result in compromising a few user accounts and an admin account, that is all an attacker needs to compromise a system. These types of attacks lead to identity theft, social security fraud, money laundering, and disclosure of highly classified information. The attacks include dictionary attacks, brute-forcing, session hijacking, and session management attacks.
Sensitive data exposure:
Sometimes web applications do not protect sensitive data and info like passwords, database credentials, etc. An attacker can easily steal or modify these weakly protected credentials and use it for illegitimate purposes. Sensitive data should be encrypted while at rest or in transit and have an extra layer of security otherwise attackers can steal it. Attackers can get their hands on sensitive exposed data and steal hashed or clear text users & database credentials off the server or a web browser. For example, if a password database uses unsalted or simple hashes to store passwords, a file upload flaw can allow an attacker to retrieve the passwords database which will lead to exposure of all passwords with a rainbow table of pre-calculated hashes.
The main flaw is not only that the data is not encrypted, even if it is encrypted, but weak key generation, weak hashing algorithms, weak cipher usage can also result in these types of one of the most common attacks. To prevent these types of attacks, first, classify which kind of data can be considered as sensitive according to the privacy laws and apply controls as per classification. Try not to store any classified data you don’t need, wash it as soon as you use it. For the data in transit, encrypt it with secure protocols i.e TLS with PFS ciphers, etc.
These types of vulnerabilities can result in the exposure of highly sensitive information like credit card credentials, health records, passwords, and any other personal data that can lead to identity theft and bank fraud, etc.
XML External Entities (XEE):
Poorly configured XML processors process external entity references inside XML documents. These external entities can be used to retrieve internal files’ data like /etc/passwd file or to perform other malicious tasks. Vulnerable XML processors can easily be exploited if an attacker can upload an XML document or include XML etc. These vulnerable XML entities can be discovered using SAST and DAST tools or manually by inspecting dependencies and configurations.
A web application is vulnerable to the XEE attack due to many reasons like if the application accepts direct XML input from untrusted sources, Document Type Definitions(DTDs) on the application are enabled, the application uses SAML for identity processing as SAML uses XML for identity insertions, etc. XEE attacks can be mitigated by avoiding serialization of sensitive data, using less complicated data formats i.e JSON, patching XML processors the application is curren’]tly using and even the libraries, disabling DTDs in all XML parsers, validation of XML file upload functionality using XSD verification, etc.
The application vulnerable to these types of attacks can lead to DOS attack, Billion Laughs’ attack, scanning of internal systems, internal port scanning, executing a remote command which results in affecting all application data.
Broken Access Control:
Access Control is giving users privileges to do specific tasks. Broken access control vulnerability takes place when the users are not properly restricted on the tasks they can perform. Attackers can exploit this vulnerability that can end up in accessing unauthorized functionality or information. Let’s say a web application allows the user to change the account he is logged in from just by changing the URL to another user’s account without further verification. Exploiting the access control vulnerability is a go-to attack of any attacker, this vulnerability can be found manually as well as by using SAFT and DAFT tools. These vulnerabilities exist due to a lack of testing and automated detection of web applications although the best way to find them is to do it manually.
Vulnerabilities contain privileges escalation i.e acting as a user you are not or acting as an admin while you are a user, bypassing access control checks just by modifying the URL or changing the application’s state, metadata manipulation, allowing the primary key to be changed as another user’s primary key, etc. To prevent these kinds of attacks, access control mechanisms must be implemented in server-side code where attackers can’t modify the access controls. Enforcement of unique application business limits by domain models, disabling of listing server directories, alert admin on repeated failed login attempts, invalidation of JWT tokens after the logout must be ensured to mitigate these kinds of attacks.
Attackers can act as another user or administrator using this vulnerability to perform malicious tasks like creating, deleting and modifying records, etc. Massive data loss can occur if the data is not secured even after a breach.
Security misconfiguration:
The most common vulnerability is security misconfiguration. The main reason for the vulnerability is the use of default configuration, incomplete configuration, Adhoc configurations, poorly configured HTTP headers, and verbose error messages containing more info than the user actually should have known. At any level of a web application, security misconfigurations can occur i.e database, web server, application server, network services, etc. Attackers can exploit unpatched systems or access unprotected files and directories to have an unauthorized hold on the system. For example, an application excessively verbose error messages that help the attacker to know vulnerabilities in the application system and the way it works. Automated tools and scanners can be used to detect these types of security flaws.
A web application contains this type vulnerability if it is missing the security hardening measures across any part of the application, unnecessary ports are open or it enables unnecessary features, default passwords are used, error handling reveals over informative errors to the attacker, it is using unpatched or outdated security software, etc. It can be prevented by removing unnecessary features of the code, i.e a minimal platform without unnecessary features, documentation, etc, enabling a task to update and patch the security holes as part of patch management processes, the use of a process to verify the effectiveness of security measures taken, the use of repeatable hardening process to make it easy to deploy another environment that is properly locked down.
These types of vulnerabilities or flaws allow the attacker to gain unauthorized access to system data which leads to the complete compromisation of the system.
Cross-Site Scripting (XSS):
XSS vulnerabilities happen at the point when a web application incorporates untrusted data in a new website page without legitimate approval or escaping, or refreshes a current site page with client-provided data, utilizing a browser API that can make HTML or JavaScript. XSS flaws occur in case the website allows a user to add custom code into a URL path which can be seen by other users. These flaws are used to run malicious JavaScript code on the target’s browser. Let’s say, an attacker can send a link to the victim containing a link to any company’s website. This connection could have some malicious JavaScript code embedded in it, In case that the bank’s webpage isn’t appropriately secured against XSS attacks, on clicking on the link the malicious code will be run on the victim’s browser.
Cross-Site Scripting is a security vulnerability that is present in almost ⅔ of the web applications. An application is vulnerable to XSS if the application stores an unsanitized user input that can be seen by another user, by the use of JavaScript structures, single-page applications, and APIs that powerfully incorporate attacker controllable information to a page are helpless against DOM XSS. XSS attacks can be mitigated by the use of frameworks that escapes and sanitize XSS input by nature like React JS etc, learning the limitations of frameworks and cover them using one’s own cases, escaping unnecessary and untrusted HTML data everywhere i.e in HTML attributes, URI, Javascript, etc, use of context-sensitive encoding in case of modifying document on client-side, etc.
XSS based attacks are of three types i.e Reflected XSS, DOM XSS, and Stored XSS. All types of these attacks have a significant amount of impact but in the case of Stored XSS, the impact is even larger i.e stealing of credentials, sending malware to the victim, etc.
Insecure deserialization:
The serialization of data means taking objects and converting them to any format so that this data can be used for other purposes later on, while deserialization of data means the opposite of that. Deserialization is unpacking this serialized data for the use of applications. Insecure deserialization means tempering of data that has been serialized just before that is about to be unpacked or deserialized. Insecure deserialization leads to the remote code execution and it is used to perform other tasks for malicious purposes like privileges escalation, injection attacks, replay attacks, etc. There are some tools available for discovering these kinds of flaws but human assistance is needed frequently to validate the problem. Exploiting deserialization is a bit difficult as the exploits won’t work without some manual changes.
When the application deserializes malicious objects supplied by the attacking entity. This can lead to two types of attacks i.e attacks related to data structure and objects in which the attacker modifies application logic or execute remote code and typical data tampering attacks in which existing data structures are used with modified content for example access control related attacks. Serialization can be used in remote process communication (RPC) or an inter-process communication (IPC), caching of data, web services, databases cache server, file systems, API authentication tokens, HTML cookies, HTML form parameters, etc. Deserialization attacks can be mitigated by not using serialized objects from untrusted sources, implementing integrity checks, isolating the code running in a low privileged environment, monitoring incoming and outgoing network connections from servers that deserialize frequently.
Using components with known vulnerabilities:
Different components like libraries, frameworks, and software modules are used by most of the developers in the web application. These libraries help the developer to avoid unnecessary work and provide the functionality needed. Attackers look for flaws and vulnerabilities in these components to coordinate an attack. In case of finding a security loophole in a component can make all the sites using the same component, vulnerable. Exploits of these vulnerabilities are already available while writing a custom exploit from scratch takes a lot of effort. This is a very common and widespread issue, the use of large amounts of components in developing a web application can lead to not even knowing and understanding all components used, patching and updating all the components is a long go.
An application is vulnerable if the developer doesn’t know the version of a component used, the software is outdated i.e the operating system, DBMS, software running, runtime environments and the libraries, the vulnerability scanning is not done regularly, the compatibility of patched software are not tested by the developers. It can be prevented by removing unused dependencies, files, documentation, and libraries, checking the version of the client and server-side components regularly, obtaining components and libraries from official and trusted secure sources, monitoring the unpatched libraries and components, ensuring a plan for updating and patching vulnerable components regularly.
These vulnerabilities lead to minor impacts but can also lead to compromisation of the server and the system. Many large breaches relied on known vulnerabilities of components. The use of vulnerable components undermine application defences and can be a starting point for a large attack.
Insufficient logging and monitoring:
Most systems don’t take enough measures and steps to detect data breaches. The average response time of an incident is 200 days after it has happened, this is a lot of time to do all the nasty stuff for an attacking entity. Insufficient logging and monitoring allow the attacker to further attack the system, maintain its hold on the system, tamper, hold and extract data as per the need. Attackers use the lack of monitoring and response in their favour to attack the web application.
Insufficient logging and monitoring occur at any time i.e logs of applications not being monitored for unusual activities, auditable events like failed login attempts and high transaction values are not properly logged, warnings and errors generate unclear error messages, no trigger alert in case of pentesting using automated DAST tools, being unable to detect or alert active attacks quickly, etc. These can be mitigated by ensuring all the login, access control failures, and server-side input validation can be logged to identify malicious user account and held for enough amount of time for delayed forensic investigation, by ensuring that the logs generated are in a format compatible with centralized log management solutions, by ensuring integrity checks at high-value transactions, by establishing a system for timely alerts of suspicious activities, etc.
Most of the successful attacks start with checking and probing for vulnerabilities in a system, allowing these vulnerability probing can result in compromising the whole system.
Conclusion:
The security vulnerabilities in a web application affect all the entities related to that application. These vulnerabilities must be taken care of to provide a safe and secure environment for the users. Attackers can use these vulnerabilities to compromise a system, get hold of it, and escalate privileges. The impact of a compromised web application can be visualized from stolen credit card credentials and identity theft to the leaking of highly confidential information etc. depending on the needs and attack vectors of malicious entities.
