About a year ago, we launched in DataLine for searching and analyzing vulnerabilities in IT applications. The service is based on the Qualys cloud solution, about the operation of which . During the year of working with the solution, we conducted 291 scans for different sites and accumulated statistics on common vulnerabilities in web applications.
In the article below, I will show exactly what kind of security holes in websites are hidden behind different levels of criticality. Let's see what vulnerabilities the scanner found especially often, why they can occur and how to protect yourself.
Qualys divides all web application vulnerabilities into three levels of severity: low, medium and high. If you look at the distribution of "severity", it seems that everything is not so bad. There are few vulnerabilities with a high level of criticality, basically all non-critical ones:
But uncritical does not mean harmless. They can also do serious damage.
Top "non-critical" vulnerabilities
- Mixed content vulnerabilities.
The site security standard is the transfer of data between a client and a server using the HTTPS protocol, which supports encryption and protects information from interception.
Some sites use mixed content: transfer part of the data through the insecure HTTP protocol. More often than not, this is how passive content - information that affects only the display of the site: pictures, css-styles. But sometimes it is transmitted active content: scripts that control the behavior of the site. In this case, with the help of special software, you can analyze information with active content coming from the server, modify your answers on the fly and make the machine work in a way that was not intended by its creators.
Newer browsers warn users that mixed content sites are not safe and block the content. Site developers also receive warnings from the browser in the console. For example, this is what it looks like in :
Why is it dangerous: Attackers use an insecure protocol to intercept information about the user, replace scripts and send requests to the site on his behalf. Even if the site visitor did not enter data, this does not protect him from phishing - Fishing out confidential information by fraudulent methods. For example, using a script, you can redirect the user to an insecure site that masquerades as a familiar one to the user. In some cases, the malicious site looks even better than the original, and the user can fill out the form himself and submit sensitive data.Things to remember as a web developer: Even if the site administrator has installed and configured an SSL/TLS certificate, the vulnerability may still be due to human error. For example, if one of the pages was set not with a relative link, but with an absolute one with http, and in addition, redirects from http to https were not set up.
You can detect mixed content on the site using a browser: search the source code of the page, read notifications in the developer console. However, the developer will have to poke around in the code for a long and tedious time. You can speed up the process with automated analysis tools, for example: , free software Lighthouse or paid software Screaming Frog SEO Spider.
Also, a vulnerability may arise due to problems with legacy-code - the code that was inherited. For example, if some of the pages are generated according to the old template, which does not take into account the transition of sites to https.
- Cookies without the "HTTPOnly" and "secure" flags.
The "HTTPOnly" attribute protects cookies from being processed by scripts that attackers use to steal user data. The "secure" flag does not allow cookies to be passed in the clear. Communication will only be allowed if the secure HTTPS protocol is used to send cookies.
Both attributes are written in the cookie properties:
Set-Cookie: Secure; HttpOnlyWhy is it dangerous: If the site developer did not specify these attributes, an attacker could intercept the user's information from the cookie and use it. If cookies are used for authentication and authorization, he will be able to hijack the user's session and perform actions on the site on his behalf.
Things to remember as a web developer: As a rule, in popular frameworks, these attributes are set automatically. But check your webserver configuration anyway and set the flag: Set-Cookie HttpOnly; secure.
However, the "HTTPOnly" attribute will make the cookie invisible to your own JavaScript as well.
- Path-Based Vulnerabilities ("path" vulnerabilities).
The scanner reports such a vulnerability if it finds a publicly accessible file or site directory with potentially sensitive information. For example, it detects individual files with system configuration or access to the entire file system. This situation is possible if access rights are set incorrectly on the site.
Why is it dangerous: If the file system sticks out, an attacker can fall into the interface of the operating system and try to find folders with passwords if they are stored in clear text (don't do that!). Or you can steal password hashes and brute-force the password, as well as try to elevate privileges in the system and move deeper into the infrastructure.
Things to remember as a web developer: Don't forget about permissions and configure the platform, web server, web application so that you can't "escape" from the web directory.
- Forms for entering sensitive data with autofill enabled.
If a user frequently fills out forms on websites, their browser saves this information using the autofill function.
Forms on websites may include fields with sensitive information, such as passwords or credit card numbers. For such fields, it is worth disabling the autocomplete function of forms on the site itself.
Why is it dangerous: If the user's browser saves sensitive information, an attacker can intercept it later, for example, through phishing. In fact, a web developer who has forgotten about this nuance is framing his users.
Things to remember as a web developer: In this case, we have a classic conflict: convenience vs security. If a web developer thinks about user comfort, he may consciously choose autocomplete. For example, if it is important to follow β recommendations on content accessibility for users with disabilities.
For most browsers, you can turn off autocomplete with the autocompete="off" attribute, for example:
<body> <form action="/en/form/submit" method="get" autocomplete="off"> <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"> </form> </body>But for Chrome it won't work. This is bypassed with JavaScript, a variant of the recipe can be found .
- The X-Frame-Options header is not set in the site code.
This header affects frame, iframe, embed, or object tags. With it, you can completely prohibit embedding your site inside the frame. To do this, you need to specify the value X-Frame-Options: deny. Or you can specify X-Frame-Options: sameorigin, then iframe embedding will only be available on your domain.
Why is it dangerous: The absence of such a header can be used on malicious sites to clickjacking. For such an attack, the attacker creates a transparent frame on top of the buttons and deceives the user. For example: scammers frame social networking pages on a website. The user thinks he is clicking on a button on this site. Instead, the click is intercepted and sends the user's request to the social network where there is an active session. This is how attackers send spam on behalf of the user or wind up subscribers and likes.
If you do not disable this feature, an attacker can place your application button on a malicious site. He may be interested in your referral program or your users.
Things to remember as a web developer: The vulnerability may occur if an X-Frame-Options with a conflicting value is set on the web server or load balancer. In this case, the server and balancer will simply rewrite the header, since they have a higher priority than the backend part code.
The deny and sameorigin values ββof the X-Frame-Options header will interfere with the operation of the Yandex webvisor. To allow using an iframe for a web browser, you need to write a separate rule in the settings. For example, for nginx, you can configure it 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 (Path-relative stylesheet import) vulnerabilities.
This is a style vulnerability on the site. It occurs when relative links like href="/en/somefolder/styles.css/" are used to refer to style files. An attacker will take advantage of this if they find a way to take the user to a malicious page. The page will substitute a relative link in its url and mimic a style call. You will get a request like badsite.ru/β¦/somefolder/styles.css/, which under the guise of style can perform malicious actions.
Why is it dangerous: An attacker could exploit this vulnerability if they find another security hole. As a result, it is possible to steal user data from cookies or tokens.
Things to remember as a web developer: Set header X-Content-Type-Options: nosniff. In this case, the browser will check the content type for styles. If the type is not text/css, the browser will block the request.
Critical vulnerabilities
- A page with a password field is transmitted from the server over an insecure channel (HTML form containing password field(s) is served over HTTP).
The response from the server over an unencrypted channel is vulnerable to "Man in the middle" attacks. An attacker can intercept traffic and intercept between the client and server as the page travels from the server to the client.
Why is it dangerous: The scammer will be able to change the page and send the user a form for confidential data that will go to the attacker's server.
Things to remember as a web developer: Some sites send users a one-time code by mail/phone instead of a password. In this case, the vulnerability is not so critical, but the mechanism will complicate the lives of users.
- Submitting a form with a login and password over an insecure 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 via an unencrypted channel.
Why is it dangerous: Unlike the previous case, this is already a critical vulnerability. Capturing sensitive data is easier because you don't even need to write code to do it.
- Using JavaScript libraries with known vulnerabilities.
During the scan, jQuery has become the most used library with an extensive range of versions. Each version has at least one or more known vulnerabilities. The impact can vary widely, depending on the nature of the vulnerability.
Why is it dangerous: There are exploits for known vulnerabilities, such as:
Things to remember as a web developer: Regularly return to the cycle: finding known vulnerabilities - fixing - checking. If you are using legacy libraries knowingly, such as to support older browsers or to save money, look for ways to fix a known vulnerability. - Cross-site scripting (XSS).
Cross-Site Scripting (XSS), or cross-site scripting, is an attack on a web application that results in malware appearing in the database. If Qualys finds such a vulnerability, then a potential attacker can inject or has already injected his own js script into the website code to perform malicious actions.Stored XSS are more dangerous, since the script is injected on the server and executed every time the attacked page is opened in the browser.
Reflected XSS easier to do as malicious script can be injected into the HTTP request. The application will receive an HTTP request, do not validate the data, pack it up, and send it immediately. If an attacker intercepts the traffic and inserts a script like
<script>/*+ΡΡΠΎ+ΡΠΎ+ΠΏΠ»ΠΎΡ ΠΎΠ΅+*/</script>then a malicious request will leave on behalf of the client.
A prime example of XSS: js sniffers that mimic pages for entering CVC, card expiration, and so on.
Things to remember as a web developer: In the Content-Security-Policy header, use the script-src attribute to force the client browser to only download and execute code from a trusted source. For example, script-src 'self' whitelists all scripts from our site only.
Best practice is Inline code: Allow only inline javascript with the unsafe-inline value. This value allows the use of inline js/css, but does not prohibit including js files. In combination with script-src 'self' we prevent external scripts from being executed.Be sure to log everything with a report-uri and look at attempts to inject into the site.
- SQL injections.
The vulnerability indicates the possibility of injecting SQL code into the site that accesses the site's database directly. SQL injection is possible if the data from the user is not escaped: it is not checked for correctness and is immediately used in the query. For example, this happens if the form on the site does not validate that the input matches the data type.Why is it dangerous: If an attacker enters an SQL query in this form, he can drop the database or give out confidential information.
Things to remember as a web developerA: Don't trust what comes from the browser. You need to protect yourself both on the client side and on the server side.
On the client side, write field validation with JavaScript.
Built-in functions in popular frameworks also help to escape suspicious characters on the server. It is also recommended to use parameterized database queries on the server.
Determine exactly where the interaction with the database takes place on the web application.
Interaction occurs when we receive any information: a request with an id (change of id), the creation of a new user, a new comment, new entries in the database. This is where sql injections can occur. Even if we delete the entry from the database, sql injection is possible.
General recommendations
Don't reinvent the wheel - use proven frameworks. Generally, popular frameworks are more secure. For .NET it is ASP.NET MVC and ASP.NET Core, for Python it is Django or Flask, for Ruby it is Ruby on Rails, for PHP it is Symfony, Laravel, Yii, for JavaScript it is Node.JS-Express.js, for Java - Spring MVC.
Keep track of vendor updates and update regularly. A vulnerability will be found, then an exploit will be written, made public, and everything will be repeated in a new way. Subscribe to updates to stable releases from a software vendor.
Check permissions. From the server side, always treat your code as if it was written from first to last letter by your most hated enemy who wants to break your site, violate the integrity of your data. Moreover, sometimes this is true.
Use clones, test sites, and then pour on the production. This will help, firstly, to avoid blunders and jambs in a productive environment: a productive environment brings money, a simple productive environment is critical. When adding, fixing or closing any problem, it is worth working in a test environment, then checking the functionality and vulnerabilities found, and then planning work with a productive environment.
Protect your web application with and integrate reports from the vulnerability scanner with it. For example, in DataLine, Qualys and FortiWeb are used as a bundle of services.
Source: habr.com