Beware of common hacks

SQL Injection Attacks

SQL Injection attacks use crafted, unusual user input to cause undesired SQL statements to be executed. An application is vulnerable to such attacks whenever it builds SQL statements directly out of raw user input. If an application builds SQL statements out of user input by using PreparedStatement correctly, then it will be protected from SQL injection attacks. If, on the other hand, it uses Statement to dynamically build SQL, or uses PreparedStatement incorrectly then it will not be protected from such attacks.

Cross-Site Scripting (XSS) Attacks

HTML allows for scripting. Scripting needs some extra care, since it allows all kinds of code to execute on the client, where it has access to the user's private environment. If you do not exercise care, it is very easy to create web applications that allow users to enter malicious scripts as regular data, into forms or URLs. When such malicious input is later fetched from the database and rendered in a view, it becomes available for execution by the browser.

Note that such scripts will execute in any browser that renders the data, not just for the browser of the hacker who happened to enter the script. When the malicious script is executing in an innocent victim's browser, it gets access to sensitive information, and sends it back to the hacker. This is called a Cross-Site Scripting (XSS) attack.

To prevent XSS attacks, ask yourself two questions:

Let's take this mock form as an example (POSTing this form does nothing):

Movie Title :
Movie Decade :

When the user POSTs this form, the data should always be validated as strongly as possible by the server. For instance, the Movie Decade should be checked against a fixed set of values, to ensure that form has not been altered by a malicious user. If the Movie Decade is indeed checked in such a manner, then it's not possible for the user to enter an arbitrary script as a value for the decade. If such strong checks are performed, then no special precautions against XSS attacks are needed.

The Movie Title is a different story, however. Since it's free-form user input, it's not possible to tightly constrain the Movie Title. The server cannot perform tight validation checks on its content, since there is no 'whitelist' of allowed values.

In this case, the user may indeed enter a script. To prevent the script from being activated when rendered in a page as regular data, special care must be taken: any special characters in free-form user input must be escaped. The Open Web App Security Project recommends that you escape these 12 characters :

Character Encoding
< &lt;
> &gt;
& &amp;
" &quot;
' &#039;
( &#040;
) &#041;
# &#035;
% &#037;
; &#059;
+ &#043;
- &#045;

The escaping can be performed in various places :

The WEB4J tool, for example, recommends performing the escaping in the Model Object, by using its SafeText class to model free-form user input instead of String.

In any case, remember that data should not be escaped more than once.

Note as well that JSTL's <c:out> tag performs escaping only for XML (5 characters), and not for HTML (12 characters). In addition, note that the JSP Expression Language performs no escaping at all.

Cross-Site Request Forgery (CSRF) Attacks

The fundamental idea in a Cross-Site Request Forgery (CSRF) attack is that of hijacking a victim's session to perform a malicious task. Since the session becomes available to the hacker, the hacker can perform tasks that would otherwise not be possible.

For example, consider a simple logging-off operation. On many sites, logging off is implemented with a simple link (GET), and not a POSTed form. A hacker can log you off such a site simply by sending you an email. Here's the scenario:

(This is why many email clients suppress the display of images.)

Defending against CSRF attacks isn't as simple as defending against XSS attacks. Usually, the defenses take this form:

Your web app framework should assist you in defending against CSRF attacks. With servlets, it's common to provide a Filter to generate and validate the special form token.

See Also :
Manage sessions closely
Beware of doubly escaped ampersands
Prefer PreparedStatement