Find and fix vulnerabilities in your application code in real-time during the development process
Of course, this list is by no means exhaustive; rather, it is more focused on the front-end aspect of web applications.
1. Source Code Vulnerabilities
Moreover, developers often install packages even for the simplest tasks, thus expanding their project dependencies. This of course can lead to security issues and have other far-reaching consequences.
While monitoring and addressing all potential application dependency vulnerabilities can be time-consuming and labor-intensive, auditing tools can help to automate and thus 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
2. Unintended Script Execution
<script>alert('You are hacked')</script>
Posting such a script would make every end user a victim unintentionally facilitating the attack by simply running the application, with the malicious code appearing to be part of the web page. While the above code is harmless, a real-life hacker could of course post far more dangerous code.
To prevent XSS attacks, developers should apply sanitization—a combination of escaping, filtering, and validating string data—when handling user input and output from the server.
3. Escaping/Encoding User Input
To prevent this, any time browser-supplied data 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.
4. Filtering Input
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 alone for protection from data manipulation. There are various techniques attackers can use to evade such filters.
5. Input Validation
Whenever possible, browser-supplied input should be validated to ensure it 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.
6. Reliance on Client-Side Validation Alone
While all of the methods discussed above are good and work well in browsers, hackers may use special tools to send data directly to the server, thus avoiding client-side validations. This would allow entry of potentially malicious or unverified data to the server. Without additional server-side validation, stored data could be corrupted or replaced with erroneous data.
The recommended best practice for preventing such scenarios is to implement 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.
7. Stealing Session Data
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.
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.
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 necessary due to specific features of the web application architecture.
8. Inducing Users to Perform Unintended Actions
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 authorization cookies.
Hackers 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.