• 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.

• 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) within the architecture consider its benefits and implement if appropriate. As a minimum the use of s DAL will help centralize the issue and its resolution. You can also use an ORM (object relational mapping). Most ORM systems use parameterized queries and this can solve many if not all SQL Injection based problems.
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. Monitor and review weblogs and application logs in order to uncover active or previous exploitation attempts.

• 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. Mark all cookies used within the application as secure. (If the cookie is not related to authentication or does not carry any personal information you do not have to mark it as secure.))

Configure your webserver to disallow using weak ciphers.

For Apache, you should modify the SSLCipherSuite directive in the httpd.conf.

	SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM

For Microsoft IIS, you should make some changes to the system registry.

• Click Start, click Run, type regedt32 or type regedit, and then click OK.
• In Registry Editor, locate the following registry key : HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders
• Set "Enabled" DWORD to "0x0" for the following registry keys:

  SCHANNEL\Ciphers\DES 56/56
  SCHANNEL\Ciphers\RC4 64/128
  SCHANNEL\Ciphers\RC4 40/128
  SCHANNEL\Ciphers\RC2 56/128
  SCHANNEL\Ciphers\RC2 40/128
  SCHANNEL\Ciphers\NULL
  SCHANNEL\Hashes\MD5
  

• OWASP - Insecure Configuration Management
• OWASP - Insufficient Transport Layer Protection

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 able to read cookies.