Validation to prevent XXS and SQL injection attacks

1. Introduction

In the last couple of years, attacks against the Web application layer have required increased attention from security professionals. This is because no matter how strong your firewall rulesets are or how diligent your patching mechanism may be, if your Web application developers haven't followed secure coding practices, attackers will walk right into your systems through port 80. The two main attack techniques that have been used widely are SQL Injection and Cross Site Scripting  attacks. SQL Injection refers to the technique of inserting SQL meta-characters and commands into Web-based input fields in order to manipulate the execution of the back-end SQL queries. These are attacks directed primarily against another organization's Web server. Cross Site Scripting attacks work by embedding script tags in URLs and enticing unsuspecting users to click on them, ensuring that the malicious Javascript gets executed on the victim's machine. These attacks leverage the trust between the user and the server and the fact that there is no input/output validation on the server to reject Javascript characters.

This article discusses techniques to detect SQL Injection and Cross Site Scripting (CSS) attacks against your networks. There has been a lot of discussion on these two categories of Web-based attacks about how to carry them out, their impact, and how to prevent these attacks using better coding and design practices. However, there is not enough discussion on how these attacks can be detected. We take the popular open-source IDS Snort , and compose regular-expression based rules for detecting these attacks. Incidentally, the default ruleset in Snort does contain signatures for detecting cross-site scripting, but these can be evaded easily. Most of them can be evaded by using the hex-encoded values of strings such as %3C%73%63%72%69%70%74%3E instead of . This is likely because most of the printed and online literature on CSS use this script as an example for determining if a site is vulnerable to CSS. These attempts can be trivially detected. However, the advanced attacker may attempt to camouflage the entire string by entering its Hex equivalents. So the