Speedran on 13 vulnerabilities on sites. Basic concepts and means of protection
Recently, I collected a kind of lecture on web security for my work, got acquainted with the well-known rating of OWASP 2013 , but was surprised to find that there was very little information in Russian, or there was practically no information available.
This, in fact, was the reason to write an article in which the main vulnerabilities, causes, examples and solutions will be described.
Some of the vulnerabilities in the list are already painted and more than once is a known fact, but without them the list would be incomplete. Therefore, I will immediately give a small content of the post:
')
There is plenty of material on the site , I personally liked this article.
By default, the identifier of the created session is saved in the browser’s cookie, except in cases when the browser’s cookies are disabled. In this case, they will be automatically substituted into each URL by the server itself.
As you can see, the ID is transmitted in clear text, while with cookies it is hidden in the header of the HTTP request.
For this, we have provided for setting a ban on session transfer via a URL:
If confidential information (money, wallet numbers, health status) is to be stored / transmitted on your site, then you should use encrypted protocols with an SSL certificate.
When setting the cookie, set the sixth parameter to secure = 1 .
If you store the password in a $ _SESSION variable or database, then you should not store it in clear text. It can only be a hash from it, or a ciphered version.
Actually, it’s easy to steal a session ID from a URL, and a little more difficult to do it with cookies.
A reliable way is to store the IP in the session, and if it suddenly became different for some reason, stop outputting anything on the page, you can even forcibly end the session.
However, there are drawbacks - the hacker and the user can sit at the firewall from the same IP, or the user can simply have a dynamic IP change right during the session.
Using SSL means that all transmitted data, including cookies, will be encrypted, which makes direct hijacking impossible. Minus - cookies can still be hijacked physically, so other methods of protection are also required.
About the completion of sessions - their life time should be set to the minimum, and always have a button to exit the account on the site.
Conclusion - this vulnerability is the second most common among web services, and using all of the above methods of struggle you can effectively protect clients from such hacking. After all, it is enough for a hacker to have a session ID, and he no longer needs a password or username to appear in his image.
Exhaustive and wonderful article: habrahabr.ru/post/149152
... but from myself I would like to add something.
Blocks loading of scripts not confirmed by attribute. (type = "text / javascript", type = "text / css")
Forbids to embed this page in iframe
Prohibit the download of anything over an unencrypted protocol (HTTP)
BeLove comment :
An important note regarding this and the previous topic is the httpOnly cookie.
This standard was introduced a long time ago, but is forgotten or ignored by many. It makes the following: makes cookies inaccessible by other means besides HTTP. Its installation means that they can not be obtained by means of JavaScript.
httpOnly is the seventh parameter of the setcookie () function in PHP.
This vulnerability is manifested when the developer specifies a direct link to an internal object, such as a file, directory or database entry, as a parameter in the URL. This allows an attacker to gain unauthorized access to the system by manipulating this parameter.
Here it is easier to immediately give examples:
You can not just forget to check whether the user is in front of us or not.
This also includes a simple protection for the number of incorrect password entry attempts.
Simply put, this is not enough or incorrectly configured server configuration file / PHP / ...
These include:
Immunity will give:
Prevention - this includes setting different passwords on different areas (SSH, MySQL, backends, hoster panel) and their regular replacement
Also, the application must have a strict architecture, where everyone understands - the project should not have the following:
As a rule, this vulnerability is already arising as a result of hacking the site, during which data was stolen that was easily readable.
Vulnerability Test:
Example # 1: The application encrypts credit card numbers in the database using default encryption. This means that when data is received, they can be quietly decoded again. The information must be encrypted with handwritten methods using a single public key, and so that only special backend applications can decrypt it using their private key.
Example # 2: A simple site that does not use SSL on all its pages. It is enough that the certificate collapsed somewhere once, so that the attacker could steal the session ID while tracking data traffic.
Example # 3: Store non-salted passwords in the database.
It is recommended not to autocomplete such information, and not to cache pages with it.
The header implies restricted access to certain functions of the application.
This will also include the simplest vulnerability, such as selecting a URL for the admin and a response from this directory. It’s bad if the hacker finds the admin folder and sees the login form. In such cases, it is appropriate to close directories by IP, or by session and redirects.
One of the most subtle types of vulnerabilities for developers. Alone, as a rule, does not bear much harm, most often the damage from it can be felt in conjunction with other vulnerabilities (XSS, unvalidated redirects)
In fact, this is my favorite method of hacking the site, and deserves a whole article with details, but what is it then speedr?
I will give a link to a wonderful description of the hole on securitylab.ru
Here everything is extremely simple, keep all connected parts of the project up to date, update to the latest stable versions, and not use any less popular or amateur modules. If there is a choice - do not use them in principle.
The bottom line is that users trusting your site can follow any links. You often met a message like "You leave our site by clicking on the link ...", so this is nothing but the simplest protection from this kind of vulnerabilities. An attacker can take advantage of this kind of redirects through your website to the pages he likes.
For example, instead of contacts.php? Act = index / site -> contacts / index / site
Such links are easier to validate.
From the name - "hijacking clicks." Above the attacker's website is a transparent iframe, with the help of the notorious social engineering, the hacker forces the user to take several specific actions. It seems to the user that he clicks the buttons / forms on one site, in fact everything is set up so that all actions are performed on the page inside the iframe. This is achieved by creating the same coordinates of buttons / forms on the attacking site and the victim site.
The peculiarity is that the user himself does not know that he enters the data "not there". To prevent this, use the tag
Popular method to extract the username / password from the victim. As a rule, E-Mail newsletters are sent to special victim databases, where the user, on behalf of this site, is prompted to proceed to the site.
For example, instead of yandex.ru it will be yandx.ru , uandex.ru , yandex.nk.me and so on.
Outwardly, it looks exactly the same as our website, on which the user is logged out. Again, by any means soc. engineering, the attacker asks the victim to log in (on his website), and simply receives a login / password. As a rule, after entering something like an authorization error message is issued, and nothing else happens.
Even browsers are now protected against phishing, as well as a large number of anti-viruses, but the problem remains relevant. In order to avoid the “rutania” of your users account, ask them to enter the password for particularly important operations (money transfer), or ask to confirm the account using SMS.
Already, perhaps, unlisted method of capturing the site.
It lies in the incorrect logic of the application, which allows you to connect any file on the server (with the wrong configuration , again).
In the address bar we see the query:
Already clearer clear, huh? As a rule, something like the following is inside:
Then your imagination can play as long as you want:
To avoid many of these errors, remember that GET is only for receiving data, for everything else there is aMaster POST .
Most of the recommendations are taken from here , translated and supplemented by me.
This, in fact, was the reason to write an article in which the main vulnerabilities, causes, examples and solutions will be described.
Some of the vulnerabilities in the list are already painted and more than once is a known fact, but without them the list would be incomplete. Therefore, I will immediately give a small content of the post:
')
- SQL Injection
- Incorrect authentication and session management
- Cross-site scripting (XSS)
- Insecure direct object links
- Insecure configuration
- Sensitive data leak
- Lack of access control to the functional level
- Cross-site request forgery (CSRF)
- Using components with known vulnerabilities
- Unvalidated Redirects
- Clickjacking
- Phishing
- Include
1. SQL Injection
There is plenty of material on the site , I personally liked this article.
2. Incorrect authentication and session management
By default, the identifier of the created session is saved in the browser’s cookie, except in cases when the browser’s cookies are disabled. In this case, they will be automatically substituted into each URL by the server itself.
index.php?PHPSESSID=jf843jgk4ogkfdjfgomg84o4og54mg As you can see, the ID is transmitted in clear text, while with cookies it is hidden in the header of the HTTP request.
For this, we have provided for setting a ban on session transfer via a URL:
php.ini session.use_trans_sid=0; session.use_only_cookies=1; .htaccess php_flag session.use_trans_sid Off php_flag session.use_only_cookies On Use encryption
If confidential information (money, wallet numbers, health status) is to be stored / transmitted on your site, then you should use encrypted protocols with an SSL certificate.
When setting the cookie, set the sixth parameter to secure = 1 .
setcookie ('example', 'content', 0, '', '', 1); If you store the password in a $ _SESSION variable or database, then you should not store it in clear text. It can only be a hash from it, or a ciphered version.
Actually, it’s easy to steal a session ID from a URL, and a little more difficult to do it with cookies.
Ways of protection:
- Avoid sessions without cookies
- Avoid third-party server authentication solutions.
- Check IP
- For particularly important actions, request a password again
- SSL certificate
- Complete sessions on time and often enough
A reliable way is to store the IP in the session, and if it suddenly became different for some reason, stop outputting anything on the page, you can even forcibly end the session.
However, there are drawbacks - the hacker and the user can sit at the firewall from the same IP, or the user can simply have a dynamic IP change right during the session.
Using SSL means that all transmitted data, including cookies, will be encrypted, which makes direct hijacking impossible. Minus - cookies can still be hijacked physically, so other methods of protection are also required.
About the completion of sessions - their life time should be set to the minimum, and always have a button to exit the account on the site.
Conclusion - this vulnerability is the second most common among web services, and using all of the above methods of struggle you can effectively protect clients from such hacking. After all, it is enough for a hacker to have a session ID, and he no longer needs a password or username to appear in his image.
3. XSS
Exhaustive and wonderful article: habrahabr.ru/post/149152
... but from myself I would like to add something.
HTTP headers:
X-Content-Type-Options: nosniffBlocks loading of scripts not confirmed by attribute. (type = "text / javascript", type = "text / css")
X-Frame-Options: DENY Forbids to embed this page in iframe
Strict-Transport-Security: max-age=expireTimeBeLove comment :
This header tells the browser that it is only necessary to work with the resource via HTTPS, i.e. sent on the first redirect from HTTP to HTTPS (to exclude mitm over HTTP. Naturally, it does not protect if the resource is visited for the first time for the browser).
An important note regarding this and the previous topic is the httpOnly cookie.
This standard was introduced a long time ago, but is forgotten or ignored by many. It makes the following: makes cookies inaccessible by other means besides HTTP. Its installation means that they can not be obtained by means of JavaScript.
alert(document.cookie); httpOnly is the seventh parameter of the setcookie () function in PHP.
4. Insecure Direct Object Links
This vulnerability is manifested when the developer specifies a direct link to an internal object, such as a file, directory or database entry, as a parameter in the URL. This allows an attacker to gain unauthorized access to the system by manipulating this parameter.
Here it is easier to immediately give examples:
- Direct link to a private photo in a closed album
- Open wallet number in GET request
- AJAX request-response by userID, which returns all user data in JSON, which are filtered on the client (funny, I met myself)
- Unclosed view / edit, for example, your profile. In the example below, the user with ID 3 can go to the profile page ID 1, and edit it
http://site.com/profile/3 http://site.com/profile/1 You can not just forget to check whether the user is in front of us or not.
This also includes a simple protection for the number of incorrect password entry attempts.
5. Insecure configuration
Simply put, this is not enough or incorrectly configured server configuration file / PHP / ...
These include:
- Open logs
- Not closed development mode (open query profiling, stack trace)
- Open config. Not main.php, for example, but main.inc
- Do not have admin / admin accounts. Even on the router in the office.
- Open access to the images folder. Closed with .htaccess or empty index.html
- And open folders like .git or .svn
Immunity will give:
- Actual versions of software used (frameworks, libs)
- Less modules and plugins
- Closing all sorts of exceptions with skittles in order to avoid the reading of code fragments or even the files responsible for a particular operation.
Prevention - this includes setting different passwords on different areas (SSH, MySQL, backends, hoster panel) and their regular replacement
Also, the application must have a strict architecture, where everyone understands - the project should not have the following:
And what is this folder that lies at the root of our third month?
6. Leakage of sensitive data
As a rule, this vulnerability is already arising as a result of hacking the site, during which data was stolen that was easily readable.
Vulnerability Test:
- Do we have any data about money / wallet numbers / state of health in the database in the open form?
- Also, in what form is this data transmitted over the network?
- Are the software versions fresh?
- Is the encryption algorithm strong enough and is it updated frequently?
Example # 1: The application encrypts credit card numbers in the database using default encryption. This means that when data is received, they can be quietly decoded again. The information must be encrypted with handwritten methods using a single public key, and so that only special backend applications can decrypt it using their private key.
Example # 2: A simple site that does not use SSL on all its pages. It is enough that the certificate collapsed somewhere once, so that the attacker could steal the session ID while tracking data traffic.
Example # 3: Store non-salted passwords in the database.
It is recommended not to autocomplete such information, and not to cache pages with it.
7. Lack of access control to the functional level
The header implies restricted access to certain functions of the application.
- Do not leave links for those who are not allowed to go there.
- Immunity will default on the withdrawal of access for everyone and from all - the principle of a white sheet and deny (*).
- Also, checking in important places of the code during the execution of an action will not interfere - when calling a function / method, put the check again.
This will also include the simplest vulnerability, such as selecting a URL for the admin and a response from this directory. It’s bad if the hacker finds the admin folder and sees the login form. In such cases, it is appropriate to close directories by IP, or by session and redirects.
site.com/admin < site.com/highlevel8. Cross-site request forgery (CSRF)
One of the most subtle types of vulnerabilities for developers. Alone, as a rule, does not bear much harm, most often the damage from it can be felt in conjunction with other vulnerabilities (XSS, unvalidated redirects)
In fact, this is my favorite method of hacking the site, and deserves a whole article with details, but what is it then speedr?
I will give a link to a wonderful description of the hole on securitylab.ru
9. Using components with known vulnerabilities
Here everything is extremely simple, keep all connected parts of the project up to date, update to the latest stable versions, and not use any less popular or amateur modules. If there is a choice - do not use them in principle.
10. Unvalidated redirects
The bottom line is that users trusting your site can follow any links. You often met a message like "You leave our site by clicking on the link ...", so this is nothing but the simplest protection from this kind of vulnerabilities. An attacker can take advantage of this kind of redirects through your website to the pages he likes.
Prevention
- Do not abuse redirects.
- If you had to, do not use user data in the request (like success.php&user_mail=eeee@eee.com)
- It is recommended to rewrite URLs by server means.
For example, instead of contacts.php? Act = index / site -> contacts / index / site
Such links are easier to validate.
11. Clickjacking
From the name - "hijacking clicks." Above the attacker's website is a transparent iframe, with the help of the notorious social engineering, the hacker forces the user to take several specific actions. It seems to the user that he clicks the buttons / forms on one site, in fact everything is set up so that all actions are performed on the page inside the iframe. This is achieved by creating the same coordinates of buttons / forms on the attacking site and the victim site.
The peculiarity is that the user himself does not know that he enters the data "not there". To prevent this, use the tag
X-Frame-Options: DENY (see above) , and a simple captcha or re-enter the password.12. Phishing
Popular method to extract the username / password from the victim. As a rule, E-Mail newsletters are sent to special victim databases, where the user, on behalf of this site, is prompted to proceed to the site.
For example, instead of yandex.ru it will be yandx.ru , uandex.ru , yandex.nk.me and so on.
Outwardly, it looks exactly the same as our website, on which the user is logged out. Again, by any means soc. engineering, the attacker asks the victim to log in (on his website), and simply receives a login / password. As a rule, after entering something like an authorization error message is issued, and nothing else happens.
Even browsers are now protected against phishing, as well as a large number of anti-viruses, but the problem remains relevant. In order to avoid the “rutania” of your users account, ask them to enter the password for particularly important operations (money transfer), or ask to confirm the account using SMS.
13. PHP Include
Already, perhaps, unlisted method of capturing the site.
It lies in the incorrect logic of the application, which allows you to connect any file on the server (with the wrong configuration , again).
In the address bar we see the query:
site.com/index.php?p=contacts.phpAlready clearer clear, huh? As a rule, something like the following is inside:
<? include($_GET['file']); ?> Then your imagination can play as long as you want:
site.com/index.php?file=../../etc/passwd%00 # redc0de: 5.3.4 site.com/index.php?file=../apache/error.log # <?shell_exec($_GET['z'])?> site.com/index.php?file=index.php # site.com/index.php?file=images/2014/06/15/12.jpg # To avoid many of these errors, remember that GET is only for receiving data, for everything else there is a
Most of the recommendations are taken from here , translated and supplemented by me.
Source: https://habr.com/ru/post/226321/
All Articles