• Reading, Updating and Deleting arbitrary data from the database
• Executing commands on the underlying operating system
• Reading, Updating and Deleting arbitrary tables from the database

1. See the remedy for solution.
2. If you are not using a database access layer (DAL), consider using one. This will help you to centralise the issue. You can also use an ORM (object relational mapping). Most of the ORM systems use only parameterised queries and this can solve the whole SQL Injection problem.
3. Locate all of the dynamically generated SQL queries and convert them to parameterised 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 was any previous but undetected attack to this resource.

• Hi-jacking users' active session
• Changing the look of the page within the victims browser.
• Mounting a successful phishing attack.
• Intercept data and perform man-in-the-middle attacks.

The issue occurs because the browser interprets the input as active HTML, Javascript or VbScript. To avoid this, all input and output from the application should be filtered. Output should be filtered according to the output format and location. Typically the output location is HTML. Where the output is HTML ensure that all active content is removed prior to its presentation to the server.

Prior to sanitizing user input, ensure you have a pre-defined list of both expected and acceptable characters with which you populate a white-list. This list needs only be defined once and should be used to sanitize and validate all subsequent input.

There are a number of pre-defined, well structured white-list libraries available for many different environments, good examples of these include, OWASP Reform and Microsoft Anti Cross-site Scripting libraries are good examples.

• XSS Cheat Sheet
• OWASP - Cross-site Scripting
• XSS Shell
• XSS Tunnelling Paper

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

• Gain full access to the database server.
• Gain a reverse shell to the database server and execute commands on the underlying operating system.
• Access the database with full permissions. Where it may be possible to read, update or delete arbitrary data from the database.
• Furthermore, depending on the platform and the database system user an attacker might carry out a privilege escalation attack to gain administrator access to the target system.

1. See the remedy for the solution.
2. Find all instances of inputs which 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 that all of the fixes have been applied properly.