.png)
Web application vulnerabilities involve a system flaw or weakness in a web-based application. They have been around for a while, mostly because form inputs need to be validated or sanitized, web servers need to be configured correctly, and there are security holes in the application design. They can be used to compromise the program's security. These vulnerabilities differ from other popular categories of vulnerabilities, including network or asset. They develop as a result of the fact that web programs must communicate with numerous users over numerous networks, and hackers can simply take advantage of that amount of accessibility.
In this blog, we are going one step above the standard OWASP top 10 either because of their complicated delivery, frequent misunderstandings or often missed. So, here are the TOP 10 most uncommon vulnerabilities in the web application that are often missed by security teams:
Expression Language Injection happens when a J2EE server's Expression Language resolvers examine user input, and one frequent way for it to happen now is via the use of Spring JSP tags.
"Expression Language" (EL) was created as part of JSTL to offer simple methods for outputting data from an object model that more closely mimics pure scripting languages. Here is an EL fragment illustration:
<c:out value=”person.address.street”/>
This code snippet locates the Java object (also known as a "bean" or "model") with the name "person," seeks up the member object "address" by searching for the getter method "getAddress()," and then locates the "street" member of that object by following the same method search pattern. It is simple to see its utility after demonstrating the identical scriptlet used to print the same data:
<%=HTMLEncoder.encode(((Person)person).getAddress().getStreet())%>
This technique would also force the page to explicitly import the Person object, which unnecessarily couples the view to the model when all that’s needed is the simple access to the bean’s attributes.
Impact
This attack can have a variety of effects, from a straightforward HttpOnly bypass to a server-side information leakage approach. The extent of this information leakage will vary largely according to the J2EE technologies being used and the breadth of the vulnerable code. A user's session ID on a browser that is currently logged into the vulnerable application can be inferred by an attacker-controlled website, which is one of the most hazardous abuse situations.
An XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser.
Vulnerabilities often occur in a parser, which is necessary for XML. With XXE, an entity can be defined based on the information contained in a file path or URL. The sensitive data is parsed, combined into the finished document, and returned to the user when the XML attack payload is read by the server.
Types of XEE attack:
Impact
This attack may lead to the disclosure of confidential data, denial of service, server-side request forgery, port scanning from the perspective of the machine where the parser is located, and other system impacts.
LDAP Injection is an attack that takes advantage of web-based applications that create LDAP statements based on user input. It is possible to alter LDAP statements using methods similar to SQL Injection when an application doesn't properly sanitize user input.
LDAP employs predicates that require the use of special characters to build queries (e.g., brackets, asterisks, ampersands, or quotes). These types of metacharacters regulate the meaning of the query, which in turn influences the kind and quantity of objects returned from the underlying directory. An attacker who can input these control characters will be able to change the query and the intended behavior.
Below is an example of an LDAP search filter:
find("(&(cn=" + username +")(Password=" + pass +"))")
The query is told to look for an LDAP node with the specified login and password using this prefix filter notation. Consider a case in which the username and password strings retrieved from an HTML form are appended to this query. A username and password value of "*" modifies the intended meaning of the query and produces a list of all users if these user-controlled data are attached to the LDAP search filter without any validation or sanitization.
Special characters other than ‘*’ can also create malicious queries. If the username value is set to ‘*)(cn=*))(|(cn=*’, the effective search filter becomes:
find("(&(cn=*)(cn=*))(|(cn=*)(Password=" + pass +"))")
If this query is used within an authentication flow, an attacker can easily bypass authentication controls with the above payload.
Impact
This could result in the execution of arbitrary commands such as granting permissions to unauthorized queries, and content modification inside the LDAP tree.
This bug investigates weaknesses in the setup of web caching features. Sometimes, when web caches choose whether or not to cache pages based solely on their extensions, an attacker could take advantage of this functionality to view the sensitive data of victims on the application.
The web caching deception (WCD) attack works by the technique of path confusion attack.
It manipulates the URL path by which the cache server is forced to store, and the sensitive data gets revealed as public content.
Using DNS rebinding, a remote attacker can get past a victim's network firewall and connect to their private home network directly using their web browser as a proxy.
A DNS Rebinding attack takes use of the fact that the name server for a domain is frequently taken over when an attacker compromises a domain by using a vulnerability (like Cross-Site Scripting—XSS).
This may alter the hostname that a person is resolving for. In other words, a specifically designed website can be accessed via a DNS Rebinding Attack by sending queries to name servers of hacked domains rather than genuine website addresses. Additionally, even if it is not a bad URL like *.youtubefilter.com or another one frequently used in phishing scams and other online attacks, all traffic received to those various IP addresses will now be forwarded back to our web server.
A CSS Injection vulnerability allows for the insertion of arbitrary CSS code into the rendered pages of a trusted website using the victim's browser. Depending on the CSS payload that is sent, this type of vulnerability has different effects. Data exfiltration or cross-site scripting could result.
This flaw appears when the program permits user-supplied CSS to conflict with the app's official stylesheets. An attacker may be given the power to execute JavaScript under specific circumstances or to extract sensitive data using CSS selectors and functions that can initiate HTTP requests by injecting code in the CSS environment. Giving people the option to alter sites by adding their own CSS files is typically quite risky.
This attack takes advantage of the path-handling functions found in several popular web languages and frameworks to mislead browsers into importing HTML pages as stylesheets. This usually allows for the injection of malicious CSS and account hijacking due to exceptionally forgiving stylesheet processing.
For instance, the browser sends a request to /styles/style.css to load styles if the current page address is /page.php. The request will instead go to /page.php/styles/style.css if you add "/" to the current address since the browser interprets this URI (/page.php/) as a directory. For PHP,.NET, JSP, and many other frameworks, a route like existing.app/any_path will call existing.app rather than throwing a 404 error. The attacker can therefore load the current HTML page as a CSS style within the same domain by adding "/" to the path.
The PRMitM attack launches a man-in-the-middle (MitM) attack at the application level by taking advantage of the similarity between the registration and password reset processes.
When a victim wants to register on the attacking website or access a specific resource on it, the attacker starts a password reset procedure with the website and sends every challenge to the victim. Among the attack's many variations is the use of a password reset process that depends on the victim's mobile phone and can be carried out by SMS or phone call.
A second-order subdomain takeover occurs when the domain that can be taken over is referred to by a primary domain in some way. Say, for illustration, that example.com is our goal. The website under that domain loads an external script, such as
<script src="https://asset.exampledomain.com"></script>
If asset.exampledomain.com in this scenario was open to a subdomain takeover, we would refer to it as a "Second Order Subdomain Takeover on example.com".
Due to the extra step required to check for second-order subdomain takeovers, the majority of people that search for subdomain takeovers do not. The procedure can be like the following:
Impact
If the second-order subdomain is used to import a script, there will be persistent XSS on all sites inside an application.
Mail Command Injection is an attack technique used to exploit mail servers and webmail applications that construct IMAP/SMTP statements from user-supplied input that is not properly sanitized. a method of attack that sends spam by inserting attacker-controlled SMTP commands into data being sent from a web application or other application to an SMTP server.
Impact
This behavior can be exploited to send copies of emails to third parties, attach viruses, deliver phishing attacks, and often alter the content of emails. It is typically exploited by spammers looking to leverage the vulnerable company's reputation to add legitimacy to their emails.
SecOps Solution is an award-winning agent-less Full-stack Vulnerability and Patch Management Platform that helps organizations identify, prioritize and remediate security vulnerabilities and misconfigurations in seconds.
To schedule a demo, just pick a slot that is most convenient for you.
.jpg)
