Indeed, developers often install packages even for the simplest tasks, thus expanding their project dependencies and this can have other far-reaching consequences.
Monitoring and addressing all potential application dependency vulnerabilities can be very time-consuming, auditing tools can be used help to automate and accelerate the process.
- Improving awareness of best practices among developers
- Proper auditing of application code to detect potential vulnerabilities
- Writing unit tests not only to ensure that code behaves as expected, but also that it executes securely
To prevent XSS attacks, code should be sanitised with a combination of escaping, filtering, and validating data strings, when handling user inputs
To prevent this, any time browser-supplied data inputs will be returned in a response (whether immediately reflected or retrieved from a database), these special characters should be replaced with escape codes for those characters.
In some situations, it might be preferable to just remove dangerous characters from the data input. This can provide some degree of protection but should not be relied on alone for protection from data manipulation. There are various techniques attackers can use to evade such filters.
Browser-supplied inputs should be validated to ensure they only contains expected characters. For instance, phone number fields should only be allowed 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.
While all of the methods discussed above are good and work well in browsers, attackers may attempt to send data directly to the server, thus avoiding client-side checks. This would allow entry of potentially malicious or unverified data to the server. Without additional server-side validation, stored data could be compromised.
Preventing such scenarios requires both client and server-side validation. This approach reduces the risk of bad data, while still providing the validation functions on the client that improve results for the end user. Front end validation should be used to inform the user immediately of issues with their input, while server validation will ensure only expected data makes its way into the application.
Stealing Session Data
Client-side script can be very powerful because 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. A common exploit of XSS attacks is to send the user’s session ID tokens to the attacker so they can hijack the session.
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 cookies.
Local and session storage browser data can also be stolen in the same way, though it cannot be secured through DOM access. It is therefore best to avoid storing sensitive information, such as tokens, in browser storage unless absolutely necessary.
Cross-site request forgery
Cross-site request forgery (CSRF) attacks attempt to trick a browser into executing malicious requests on the websites the user is already logged in to, even if the site is not actually opened at that time. If sessions on the target site are cookie-based, requests to that site can be automatically enriched with authorisation cookies.
Attackers can also implement their own web pages and have them perform malicious requests to other sites in the background when the user opens it. They can also use social media, forums, and other platforms to post malicious links or other content that forces browsers to make unnoticed calls to other sites using the user’s session cookies.
The general technique for avoiding this vulnerability is implementing tokenization of client-server communication in which an additional token is introduced that is not stored in cookies. Tokens should be generated for each form on the website upon session establishment and should be sent together with each request while the user is present on the website.
- Encrypt: Use HTTPS/SSL to encrypt data exchanged between the client and the server.
- 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.
- Use safe methods of DOM manipulation: Methods such as innerHTML are powerful and potentially dangerous, as they don’t limit or escape/encode 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.