- executing unintended script content,
- intrusion using a user’s established session data,
- user account tampering,
- data theft via browser-side storage,
- modification or addition of dynamically generated web page content.
- awareness of best practices among developers,
2. Cross-Site Scripting (XSS)
3. escape input from the user
4. validate input
6. Cross-Site Request Forgery (CSRF)
Without additional server-side validation, stored data could be corrupted or replaced with erroneous data.
2. Cross-Site Scripting (XSS)
Repair: Defense against XSS can be approached in several ways. Ultimately the best approach is a combination of the following:
Escape input from the user
Wherever possible, browser-supplied input should be validated to ensure it only contains expected characters. For instance, phone number fields should only be permitted to contain numbers and perhaps a dash or parentheses characters. Input containing characters outside the expected set should be immediately rejected. These filters should be set up to look for acceptable characters and reject everything else.
In some cases, it might be preferable to simply remove dangerous characters from the data received as input. This can provide some degree of protection but should not be relied on as sole protection from data manipulation. There are various techniques attackers can use to evade such filters.
Use safe methods for manipulating the DOM
Client-side script sometimes modifies elements in the DOM directly. Methods such as innerHTML are very powerful and potentially dangerous as they don’t limit or escape the values that are passed to them. Using a method like innerText instead provides inherent escaping of potentially hazardous content. This is particularly useful in preventing DOM-based XSS attacks.
3. Sensitive cookie exposure
Client-side browser script can be very powerful in that it has access to all the content returned by a web application to the browser. This includes cookies that could potentially contain sensitive data including user session IDs. In fact, a common exploit of XSS attacks is to send the user’s session ID tokens to the attacker so they can hijack the session.
Repair: To prevent this, most browsers now support the HTTP-Only attribute on cookies. When the server sets a cookie on the browser, setting the HTTP-Only attribute tells the browser not to allow access to the cookie from the DOM. This prevents client-side script-based attacks from accessing the sensitive data stored in those cookies.
- avoid eval()—don’t utilize this command in code. There are better and more secure options.
- encrypt—use HTTPS/SSL to encrypt data exchanged between the client and the server. This is especially critical for sites where user information and passwords are exchanged, or where confidential information such as account numbers or social security numbers are involved.
- set Secure Cookies—to ensure SSL/HTTPS is in use, set your cookies as “Secure,” which limits the use of your application’s cookies to only secure web pages.
- set API access keys—assign individual tokens for each end-user. If these tokens don’t match up, access can be denied or revoked.