About a year ago, we at DataLine launched a service for searching and analyzing vulnerabilities in IT applications. The service is based on the cloud solution Qualys, about which . Over the course of a year, we have conducted 291 scans for various websites and accumulated statistics on common vulnerabilities in web applications.
In the article below, I will show you what security holes in websites are hidden behind different levels of severity. Let's look at which vulnerabilities the scanner found most frequently, why they may occur, and how to protect against them.
Qualys categorizes all web application vulnerabilities into three levels of severity: low, medium, and high. Looking at the distribution by 'seriousness', it seems that things aren't so bad. There are few vulnerabilities with high severity; mostly, they are non-critical:
But non-critical doesn't mean harmless. They can also cause serious damage.
Top 'non-critical' vulnerabilities
- Vulnerabilities related to mixed content.
It is a security standard for websites to transmit data between the client and server using the HTTPS protocol, which supports encryption and protects information from interception.
Some websites use mixed content: they transmit part of the data via the unsecured HTTP protocol. More often, this is done for passive content , information that only affects the display of the site: images, CSS styles. But sometimes it also involves active content: scripts that manage the behavior of the site. In this case, using special software, one can analyze the incoming server information containing active content, modify responses on the fly, and make the system behave in ways not intended by its creators.
New browser versions warn users that sites with mixed content are unsafe and block the content. Website developers also receive warnings from the browser in the console. For example, this is how it appears in :
What's dangerous about it: Malicious actors use the unsecured protocol to intercept user information, spoof scripts, and send requests to the site on its behalf. Even if a website visitor has not entered any data, this does not protect them from phishing. – extracting confidential information through fraudulent methods. For example, a script can redirect a user to an insecure website masquerading as a familiar one. In some cases, the malicious site may even look better than the original, and the user might fill out a form and submit confidential data themselves.Important Considerations for Web Developers: Even if the site administrator has installed and configured an SSL/TLS certificate, vulnerabilities can arise due to human factors. For instance, if an absolute link using http is set on one of the pages instead of a relative link, and no redirects from http to https are configured.
Mixed content on a website can be detected using a browser: searching through the page's source code and checking notifications in the developer console. However, the developer may have to sift through the code painstakingly. The process can be accelerated with automated analysis tools, such as: , free software Lighthouse, or the paid tool Screaming Frog SEO Spider.
Vulnerabilities can also arise from legacy code—code inherited from previous systems. For example, if some pages are generated using an old template that does not account for the site's transition to https.
- Cookies without the 'HTTPOnly' and 'secure' flags.
The 'HTTPOnly' attribute protects cookie files from being accessed by scripts that attackers use to steal user data. The 'secure' flag prevents cookies from being transmitted in plaintext. Data exchange will only be allowed if a secure HTTPS protocol is used to send cookies.
Both attributes are specified in the cookie properties:
Set-Cookie: Secure; HttpOnlyWhat's dangerous about it: If the web developer did not specify these attributes, an attacker could intercept user information from cookies and exploit it. If cookies are used for authentication and authorization, they could hijack the user's session and perform actions on the site in their name.
Important Considerations for Web Developers: Typically, in popular frameworks, these attributes are set automatically. However, still check the web server configuration and set the flag: Set-Cookie HttpOnly; Secure.
The 'HTTPOnly' attribute will also make cookies invisible to your own JavaScript.
- Path-Based Vulnerabilities.
The scanner reports such a vulnerability if it finds a publicly accessible file or directory on the website with potentially sensitive information. For example, it may detect individual configuration files or access to the entire file system. This situation can occur if the access rights on the site are incorrectly set.
What's dangerous about it: If the file system is exposed, an attacker can penetrate the operating system interface and try to find folders containing passwords if they are stored in plain text (do not do this!). Alternatively, they can steal password hashes and attempt to crack the password, as well as try to escalate privileges within the system and delve deeper into the infrastructure.
Important Considerations for Web Developers: Do not forget about access rights and configure the platform, web server, and web application so that it is not possible to 'escape' from the web directory.
- Forms for entering confidential data with the autofill feature enabled.
If a user frequently fills out forms on websites, their browser saves this information using the autofill feature.
Forms on websites may include fields with confidential information, for example, passwords or credit card numbers. For such fields, it is advisable to disable the autofill feature on the site itself.
What's dangerous about it: If the user's browser saves confidential information, an attacker can intercept it later, for example, through phishing. Essentially, a web developer who forgets about this nuance is putting their users at risk.
Important Considerations for Web Developers: In this case, we have a classic conflict: convenience vs. security. If the web developer prioritizes user comfort, they may consciously choose autofill. For example, if it is important to follow – recommendations for making content accessible to users with disabilities.
For most browsers, the autofill can be disabled with the attribute autocomplete="off", for example:
<body> <form action="/en/form/submit/" method="get" autocomplete="off" data-trp-original-action="/form/submit"> <div> <input type="text" placeholder="First Name"> </div> <div> <input type="text" id="lname" placeholder="Last Name" autocomplete="on"> </div> <div> <input type="number" placeholder="Credit card number"> </div> <input type="submit"> <input type="hidden" name="trp-form-language" value="en"/></form> </body>But for Chrome, it won't work. This can be circumvented using JavaScript; a variant of the solution can be found .
- The website code does not specify the X-Frame-Options header.
This header affects frame, iframe, embed, or object tags. It can completely forbid embedding your site within a frame. To do this, set the value of X-Frame-Options to deny. Alternatively, you can set X-Frame-Options to sameorigin, allowing embedding in an iframe only on your domain.
What's dangerous about it: The absence of such a header can be exploited on malicious sites for clickjacking. In this type of attack, the perpetrator creates a transparent frame over buttons and deceives the user. For instance, fraudsters embed a frame with social media pages on a site. The user thinks they are clicking a button on this site. Instead, the click is intercepted, sending the user's request to the social network, where an active session exists. This way, attackers spread spam in the user's name or inflate followers and likes.
If this possibility is not restricted, an attacker could place a button for your application on a malicious site. They may be interested in your referral program or your users.
Important Considerations for Web Developers: A vulnerability can arise if conflicting values for X-Frame-Options are set on the web server or load balancer. In this case, the server and load balancer will simply overwrite the header, as they take precedence over the backend code.
The values deny and sameorigin for the X-Frame-Options header will interfere with Yandex's webvisor functionality. To allow iframe usage for the webvisor, a separate rule must be specified in the settings. For example, for nginx, it can be configured like this:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - PRSSI vulnerabilities (Path-relative stylesheet import).
This is a vulnerability in site styles. It occurs when relative links of the form href="/somefolder/styles.css/" are used to access style files. An attacker will exploit this if they find a way to redirect the user to a malicious page. The page will insert a relative link in its URL that mimics access to the styles. The result will be a request like badsite.ru/.../somefolder/styles.css/, which can perform malicious actions under the guise of a style.
What's dangerous about it: A scammer could exploit this vulnerability if they find another hole in security. As a result, user data could be stolen from cookies or tokens.
Important Considerations for Web Developers: Set the header X-Content-Type-Options: nosniff. In this case, the browser will check the content type for styles. If the type differs from text/css, the browser will block the request.
Critical vulnerabilities
- A page with a password field is served over an unsecured channel (HTML form containing password field(s) is served over HTTP).
Responses from the server over an unencrypted channel are vulnerable to man-in-the-middle attacks. An attacker could intercept traffic and insert themselves between the client and the server as the page is sent from the server to the client.
What's dangerous about it: A scammer could replace the page and send the user a form for confidential data, which would then go to the attacker's server.
Important Considerations for Web Developers: Some sites send users a one-time code via email/phone instead of a password. In this case, the vulnerability is not as critical, but the mechanism complicates life for users.
- Submitting a form with a username and password over an unsecured channel (Login Form Is Not Submitted Via HTTPS).
In this case, a form with a username and password is sent from the user to the server over an unencrypted channel.
What's dangerous about it: Unlike the previous case, this is already a critical vulnerability. Intercepting confidential data is easier since no code needs to be written for this.
- Using JavaScript libraries with known vulnerabilities.
During scanning, the most commonly used library has become jQuery with an extensive range of versions. Each version has at least one, if not more, known vulnerabilities. The impact can vary widely depending on the nature of the vulnerability.
What's dangerous about it: For known vulnerabilities, there are exploits, such as:
Important Considerations for Web Developers: Regularly return to the cycle: searching for known vulnerabilities – remediation – verification. If you are consciously using outdated libraries, for example, to support older browsers or to save budget, look for opportunities to remediate known vulnerabilities. - Cross-site scripting (XSS).
Cross-Site Scripting (XSS), or cross-site scripts, are attacks on web applications that result in malware being stored in the database. If Qualys finds such a vulnerability, it means a potential attacker can inject or has already injected their JS script into the site's code to perform malicious actions.Stored XSS is more dangerous because the script is injected on the server and executes every time the attacked page is opened in a browser.
Reflected XSS is easier to conduct, as the malicious script can be injected into an HTTP request. The application will receive the HTTP request, not validate the data, package it, and immediately send it. If the attacker intercepts the traffic and inserts a script like
<script>/*+что+то+плохое+*/</script>then a malicious request will be sent on behalf of the client.
A vivid example of XSS: JS sniffers that imitate pages for entering CVC, card expiration date, and so on.
Important Considerations for Web Developers: In the Content-Security-Policy header, use the script-src attribute to ensure the client's browser loads and executes code only from a trusted source. For example, script-src 'self' whitelists all scripts from our site only.
The best practice is Inline code: allow only inline JavaScript by using the value unsafe-inline. This value permits the use of inline JS/CSS but does not prohibit linking JS files. Together with script-src 'self', we prevent the execution of external scripts.Ensure all actions are logged using report-uri and monitor attempts to inject into the site.
- SQL injections.
The vulnerability indicates the possibility of injecting SQL code into the site that directly accesses the site database. SQL injection is possible if user data is not escaped: it is not validated and is immediately used in the request. For example, this occurs if a form on the site does not check the input data type.What's dangerous about it: If an attacker inputs an SQL query into such a form, they could bring down the database or expose confidential information.
Important Considerations for Web Developers: Do not trust anything coming from the browser. Protection should be implemented on both the client and server sides.
On the client side, implement field checks using JavaScript.
Built-in features in popular frameworks also help escape suspicious characters on the server. It is also recommended to use parameterized queries for databases on the server.
Identify where the interaction with the database occurs in the web application.
Interaction occurs when we retrieve any information: a request with an id (changing the id), creating a new user, a new comment – new entries in the database. SQL injections can arise here. Even if we delete an entry from the database, an SQL injection is possible.
General recommendations
Don't reinvent the wheel – use proven frameworks. Generally, popular frameworks are more secure. For .NET, this includes ASP.NET MVC and ASP.NET Core; for Python, it's Django or Flask; for Ruby, Ruby on Rails; for PHP, Symfony, Laravel, Yii; for JavaScript, Node.JS - Express.js; for Java, Spring MVC.
Keep an eye on vendor updates and update regularly. Vulnerabilities will be discovered, then exploits will be written, made publicly available, and it will all repeat. Subscribe to updates for stable versions from the software vendor.
Check access rights. Always treat your code on the server side as if it were all written by your most hated enemy, who wants to break your site and compromise your data integrity. Especially since sometimes this is indeed the case.
Use clones and test environments before deploying to production. This will help, first of all, avoid mistakes and blunders in the production environment: the production environment generates revenue, and downtime in production is critical. When adding, fixing, or closing any issues, work should be done in a test environment, then check functionality and found vulnerabilities, and only after that plan work in the production environment.
Protect your web application with and integrate vulnerability scanner reports with it. For example, in DataLine, Qualys and FortiWeb are used as a service integration.
Source: habr.com
