1. See the remedy for solution.
2. If possible, do not invoke system commands from the application.
3. Find all instances of similar code and make the code changes outlined in the remedy section.

• Command Injection Vulnerability
• OWASP - Command Injection
• WASC - OS Commanding

• Process class in .NET
• Program execution Functions in PHP

• Wherever possible, do not allow the appending of file paths as a variable. File paths should be hard-coded or selected from a small pre-defined list.
• Where dynamic path concatenation is a major application requirement, ensure input validation is performed and that you only accept the minimum characters required - for example "a-Z0-9" - and that you filter out and do not allow characters such as ".." or "/" or "%00" (null byte) or any other similar multifunction characters.
• It's important to limit the API to only allow inclusion from a directory or directories below a defined path.

• WASC - Remote File Inclusion
• Remote File Inclusion Vulnerabilities Information & Prevention

1. See the remedy for solution.
2. If you are not using a database access layer (DAL), consider using one. This will help you centralize the issue. You can also use ORM (object relational mapping). Most of the ORM systems use only parameterized queries and this can solve the whole SQL injection problem.
3. Locate all of the dynamically generated SQL queries and convert them to parameterized queries. (If you decide to use a DAL/ORM, change all legacy code to use these new libraries.)
4. Use your weblogs and application logs to see if there were any previous but undetected attacks to this resource.

• OWASP SQL injection
• SQL Injection Cheat Sheet
• SQL Injection Vulnerability

• SQL injection Prevention Cheat Sheet
• A guide to preventing SQL injection

The issue occurs because the browser interprets the input as active HTML, JavaScript or VBScript. To avoid this, output should be encoded according to the output location and context. For example, if the output goes in to a JavaScript block within the HTML document, then output needs to be encoded accordingly. Encoding can get very complex, therefore it's strongly recommended to use an encoding library such asOWASP ESAPIandMicrosoft Anti-cross-site scripting.

Additionally, you should implement a strong Content Security Policy (CSP) as a defense-in-depth measure if an XSS vulnerability is mistakenly introduced. Due to the complexity of XSS-Prevention and the lack of secure standard behavior in programming languages and frameworks, XSS vulnerabilities are still common in web applications.

CSP will act as a safeguard that can prevent an attacker from successfully exploiting Cross-site Scripting vulnerabilities in your website and is advised in any kind of application. Please make sure to scan your application again with Content Security Policy checks enabled after implementing CSP, in order to avoid common mistakes that can impact the effectiveness of your policy. There are a few pitfalls that can render your CSP policy useless and we highly recommend reading the resources linked in the reference section before you start to implement one. 

• OWASP - Cross-site Scripting
• Cross-site Scripting Web Application Vulnerability
• XSS Shell
• XSS Tunnelling

• Microsoft Anti-XSS Library
• Negative Impact of Incorrect CSP Implementations
• Content Security Policy (CSP) Explained
• OWASP XSS Prevention Cheat Sheet
• OWASP AntiSamy Java

Generated XSS exploit might not work due to browser XSS filtering. Please follow the guidelines below in order to disable XSS filtering for different browsers. Also note that;

• XSS filtering is a feature that's enabled by default in some of the modern browsers. It should only be disabled temporarily to test exploits and should be reverted back if the browser is actively used other than testing purposes.
• Even though browsers have certain checks to prevent Cross-site scripting attacks in practice there are a variety of ways to bypass this mechanism therefore a web application should not rely on this kind of client-side browser checks.

Chrome

• Open command prompt.
• Go to folder where chrome.exe is located.
• Run the command chrome.exe --args --disable-xss-auditor

Internet Explorer

• Click Tools->Internet Options and then navigate to the Security Tab.
• Click Custom level and scroll towards the bottom where you will find that Enable XSS filter is currently Enabled.
• Set it to disabled. Click OK.
• Click Yes to accept the warning followed by Apply.

Firefox

• Go to about:configin the URL address bar.
• In the search field, type urlbar.filterand find browser.urlbar.filter.javascript.
• Set its value to falseby double clicking the row.

Safari

• To disable the XSS Auditor, open Terminal and executing the command:  defaults write com.apple.Safari "com.apple.Safari.ContentPageGroupIdentifier.WebKit2XSSAuditorEnabled" -bool FALSE
• Relaunch the browser and visit the PoC URL
• Please don't forget to enable XSS auditor again:  defaults write com.apple.Safari "com.apple.Safari.ContentPageGroupIdentifier.WebKit2XSSAuditorEnabled" -bool TRUE

• If possible, do not permit appending file paths directly. Make them hard-coded or selectable from a limited hard-coded path list via an index variable.
• If you definitely need dynamic path concatenation, ensure you only accept required characters such as "a-Z0-9" and do not allow ".." or "/" or "%00" (null byte) or any other similar unexpected characters.
• It is important to limit the API to allow inclusion only from a directory and directories below it. This way you can ensure any potential attack cannot perform a directory traversal attack.

• Local File Inclusion Vulnerability

1. See the remedy for solution.
2. Move all of your critical forms and pages to HTTPS and do not serve them over HTTP.

Do not leave SVN repository files on production environments. If there is a business requirement to do so, implement access control mechanisms to stop public access to SVN repository files.

You can also use Exportif you do one time deployments, instead of a checkout.

• Authorization and Permissions in SQL Server (ADO.NET)
• Wikipedia - Principle of Least Privilege
• How to Use MySQL GRANT to Grant Privileges to Account

• Where possible do not use users' input for URLs.
• If you definitely need dynamic URLs, make a list of valid accepted URLs and do not accept other URLs.
• Ensure that you only accept URLs which are located on accepted domains.
• Use CSP to whitelist iframe source URLs explicitly.

• OWASP - Cross Frame Scripting
• Frame Injection Attacks
• Content Security Policy (CSP) Explained

1. See the remedy for solution.
2. Consider marking all of the cookies used by the application as HTTPOnly. (After these changes javascript code will not be able to read cookies.)

• Netsparker - Security Cookies - HTTPOnly Flag
• OWASP HTTPOnly Cookies
• MSDN - ASP.NET HTTPOnly Cookies

• Send additional information in each HTTP request that can be used to determine whether the request came from an authorized source. This "validation token" should be hard to guess for attacker who does not already have access to the user's account. If a request is missing a validation token or the token does not match the expected value, the server should reject the request.

• If you are posting form in ajax request, custom HTTP headers can be used to prevent CSRF because the browser prevents sites from sending custom HTTP headers to another site but allows sites to send custom HTTP headers to themselves using XMLHttpRequest.

  • For native XMLHttpRequest (XHR) object in JavaScript;

    xhr = new XMLHttpRequest();
    xhr.setRequestHeader('custom-header', 'valueNULL');
    

    For JQuery, if you want to add a custom header (or set of headers) to

    a. individual request

    $.ajax({
        url: 'foo/bar',
        headers: { 'x-my-custom-header': 'some value' }
    });
    

    b. every request

    $.ajaxSetup({
        headers: { 'x-my-custom-header': 'some value' }
    });
    OR
    $.ajaxSetup({
        beforeSend: function(xhr) {
            xhr.setRequestHeader('x-my-custom-header', 'some value');
        }
    });
    

• OWASP Cross-Site Request Forgery (CSRF)

• OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

1. Add the attribute autocomplete="off"to the form tag or to individual "input" fields. However, since early 2014, major browsers don't respect this instruction, due to their integrated password management mechanism, and offer to users to store password internally.
2. Find all instances of inputs that store private data and disable autocomplete. Fields which contain data such as "Credit Card" or "CCV" type data should not be cached. You can allow the application to cache usernames and remember passwords; however, in most cases this is not recommended.
3. Re-scan the application after addressing the identified issues to ensure all of the fixes have been applied properly.

• Apply sandboxing in inline frame

  <iframe sandbox src="framed-page-url"></iframe>
  

• For untrusted content, avoid the usage of seamlessattribute and allow-top-navigation, allow-popupsand allow-scriptsin sandbox attribute.

• HTML5 Security Cheat Sheet

• How to Safeguard your Site with HTML5 Sandbox
• Play safely in sandboxed IFrames

• Cross Site Tracing
• Web Servers Enable HTTP TRACE Method by Default

• An Introduction to Content Security Policy
• Content Security Policy (CSP) HTTP Header
• Content Security Policy (CSP)

• Security Cookies - SameSite Attribute - Netsparker
• Using the Same-Site Cookies Attribute to Prevent CSRF Attacks
• Same-site Cookies
• Preventing CSRF with the same-site cookie attribute
• SameSite cookies explained
• Get Ready for New SameSite=None; Secure Cookie Settings

• Subresource Integrity
• Do not let your CDN betray you: Use Subresource Integrity
• Web Application Security with Subresource Integrity
• SRI Hash Generator