Risk Name
 Risk Description
 Prevention
SQL Injection
 Input some sql statement in html form's text field (For example, search condition), which may cause additional harmful SQL (Eg. delete) to be executed when server executes the search sql and comprosing data safety.
Use preparedStatement with parameters instead of dire string concatiation to form a SQL statement.
JS Injection
 Input some javascript in html form's text field. On submission, the javascript will be saved, without proper escaping, the next time the field value is displayed, the script can be automatically executed

Use jstl tag to display  which performs proper xml escaping on displaying

Also on form submission, a Filter can be implemented to scan all request parameters and leverage apache commons' StringEscapeUtils.escapeXml to to perform proper escaping

Session hijacking

Steal customer's jsessionId cookie to simulate a logged on user. Then the attacker can gain access to user's sensitive or even modify user's data.  


Eg. As an example, an attacker may post a message on www.example.com with the following link:
Click here!


Cross-site scripting: a cookie that should be only exchanged between a server and a client is sent to another party.


When another user clicks on this link, the browser executes the piece of code within the onclick attribute, thus replacing the string document.cookie with the list of cookies that are accessible from the current page. As a result, this list of cookies is sent to the attacker.com server. If the attacker's malicious posting is on an HTTPS website https://www.example.com, secure cookies will also be sent to attacker.com in plain text.

SessionFixationProtection:

Eg: Spring security can use the following configuration



This virtually creates a new session on user login and copy all attributes to the new session.


Do not use url rewritting to track session:

Before tomcat 7. 

server.xml:

disableURLRewriting="true">


After tomcat 7: this is part of the servlet 3's standard feature. In web.xml:


        COOKIE

XSS Attack
 XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy.

Use a XSSFilter that use regular expression pattern matching to strip potential XSS chars


xss.filter.rule.script_fragments=(?i)

xss.filter.rule.src=(?ims)[\\s\r\n]+src[\\s\r\n]*=[\\s\r\n]*'(.*?)'

xss.filter.rule.lonely_script_tags=(?i)

xss.filter.rule.lonely_script_tags2=(?ims)

xss.filter.rule.eval=(?ims)eval\\((.*?)\\)

xss.filter.rule.expression=(?ims)expression\\((.*?)\\)

xss.filter.rule.javascript=(?i)javascript:

xss.filter.rule.vbscript=(?i)vbscript:

xss.filter.rule.onload=(?ims)onload(.*?)=
Replay Attack
 Intercept user's request and send the same request again. Data encryption cannot prevent such attack and user's data may be comproised. Eg. Deduct from bank account twice

CSRF Token

  1. A random CSRF Token is generated and is stored in session.

  2. The CSRF Token is written to http response as a hidden field

  3. Customer submit the form with CSRF token

  4. The application verify the existence of CSRF Token and compare it with the CSRF Token stored in session. Accepting the request only if both match.

  5. The CSRF Token is only valid for one request, it will be cleared on request submission and a new one will be generated next time
Data integrity tampering

One possible form of man-in-the-middle attack. Attacker can assume the identity of the user and send some malicous information to server, or intercept the user's request and modify some key information.

Digital signature

Client and server use a shared secret with private/public key pair.

Before sending a request to server, client computes a hash of the critical information and encrypt it with its private key as a digital signature.

Once the server received the request it will decrpt the information using the client's public key, then compute a hash of the crital information again. If the decryption is successful and the hash matches. It can be assured that the integreity and authenticity of the critial information


Other things to notice:

  • Always use POST/PUT for data submission

  • Always force HTTPS for sensitive data communication with server:

    In Spring security configuration: and define port mapping as The server will send a redirect response automatically to HTTPS

  • Always send cookie via HTTPS channel:

    For cookies that contain sensitive information, always set the attribute "secure" as "true". In web.xml for servlet 3:

    true

  • Prevent Javascript from manipulating cookie:

    For cookies that contain sensitive information, always set the attribute "httponly" as "true". In web.xml for servlet 3:

    >true

    In tomcat's server.xml: useHttpOnly="true">