PreparedStatementcorrectly, then it will be protected from SQL injection attacks. If, on the other hand, it uses
Statementto dynamically build SQL, or uses
PreparedStatementincorrectly then it will not be protected from such attacks.
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:
POSTing this form does nothing):
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.
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.
Movie Title is a different story, however.
Since it's free-form user input, it's not possible to tightly constrain the
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 :
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
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.
For example, consider a simple logging-off operation.
On many sites, logging off is implemented with a simple link (
GET), and not a
A hacker can log you off such a site simply by sending you an email. Here's the scenario:
'src'attribute points to the log-off link
IMGtag is encountered by your email client, it extracts the
srctarget and sends an HTTP
GETrequest over the network, ostensibly to fetch the 'image'
Defending against CSRF attacks isn't as simple as defending against XSS attacks. Usually, the defenses take this form:
method='GET'or a link
POSTed form, the server verifies that the hidden parameter is present, and has the expected value for the current session. All of this has the intent of answering a simple question: 'Did this POSTed form really come originally from the legitimate server, or from some unknown third party?'
content-typeof the response as an HTTP header. When using form tokens, the
content-typelets tools know when you are serving HTML - if your are serving plain text or XML (which doesn't contain a form), then there's no need to inject form tokens.