|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.|
Use jstl tag <c:out …> 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
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:
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.
Eg: Spring security can use the following configuration
<security:session-management session-fixation-protection=”migrateSession” />
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.
<Context path=”xxx” docBase=”xxx” disableURLRewriting=”true”>
After tomcat 7: this is part of the servlet 3’s standard feature. In web.xml:
|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
|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||
|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.
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: <security:intercept-url pattern=”xxxx” requires-channel=”https”></security:intercept-url> and define port mapping as <security:port-mappings><security:port-mapping http=”80″ https=”443″ /></security:http> 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:
For cookies that contain sensitive information, always set the attribute “httponly” as “true”. In web.xml for servlet 3:
In tomcat’s server.xml: <Context path=”xxx” docBase=”xxx” useHttpOnly=”true”>