The principle of defense in depth (combining multiple best practices) is necessary for defending against Session Fixation attacks. These include to:
1.Ensure that only server generated session values are accepted by the application.
2.Upon a successful login, invalidate the original session value, and re-issue a new session value.
3.Prevent the application from accepting session values via GET or POST requests and instead store session values within HTTP Cookies only.
To defend against Cross Site Scripting attacks within the application user’s Browser Document Object Model (DOM) environment a defense-in-depth approach is required, combining a number of security best practices.
Note You should recall that for Stored XSS and Reflected XSS injection takes place server side, rather than client browser side.
Due to the very large attack surface developers are strongly encouraged to review areas of code that are potentially susceptible to DOM XSS, including but not limited:
window.name document.referrer document.URL document.documentURI location location.href location.search location.hash eval setTimeout setInterval document.write document.writeIn innerHTML outerHTML.
Let’s apply a suitable Regex pattern to remediate this particular DOM XSS vulnerability.
Cross Site Request Forgery Post
To be effective, each response from the web server requires a Random Token to be generated. This token is then inserted by the application, as a hidden parameter, into sensitive form fields.
By taking this approach, the application can then check, whenever a user submits/posts a form, that the token is both valid and correct. Because an attacker should never know this randomly generated value, it is a good strategy to protect against CSRF attacks.
In essence it allows the application to determine the answer to this simple question: Was the form that the user POSTed legitimately created by the application (valid) or by an unknown third party (invalid)?’
Note wherever cryptographically secure pseudo-random number generation (pRNG) is required, the wheel should not be re-invented. Correct use of java.security.SecureRandom is strongly preferred over bespoke/custom random number generation code, the latter being extremely prone to developer error.