June 16, 2014 at 11:02Speedran on 13 vulnerabilities on sites. Basic concepts and remedies
Recently, I collected a kind of lecture on web security at work, got acquainted with the well-known OWASP vulnerability rating of 2013 , but was surprised to find that there is very little correct information in Russian, or it is practically nonexistent.
This, in fact, was the reason to write an article in which the main vulnerabilities, reasons, examples and solutions will be described thesis.
Some of the vulnerabilities provided in the list have already been described more than once - a well-known fact, but without them the list would be incomplete. Therefore, I will immediately give a small post content:
There is plenty of material on the site , I personally liked this article.
By default, the identifier of the created session is stored in the browser cookie, unless the cookie is disabled in the browser. In this case, they will automatically be substituted into each URL by the server itself
As you can see, the ID is transmitted in the clear, while with cookies it is hidden in the header of the HTTP request.
To do this, provide for the prohibition of sending sessions through the URL:
If confidential information (money, wallet numbers, health status) should be stored / transmitted on your site, then it is worth using encrypted protocols with an SSL certificate.
In this case, when setting a cookie, set the sixth parameter secure = 1 .
If you store the password in the $ _SESSION variable or the database, then you should not store it in the clear. It can only be a hash from it, or a scripted version.
Actually, it’s easy to steal the session ID from the URL, and it’s a little harder to do with cookies.
A reliable way is to store the IP in the session, and if for some reason it suddenly starts to differ, stop displaying anything on the page, you can even forcefully end the session.
However, there are drawbacks - the cracker and the user can sit behind 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, this makes direct hijacking of cookies impossible. Less - cookies can still be stolen physically, so other protection methods are also required.
About the completion of sessions - their life should be set to a 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 quite effectively protect customers from such a hack. After all, a hacker just needs to have a session ID, and he will no longer need a password or username to appear in his image.
An exhaustive and wonderful article: habrahabr.ru/post/149152
... but I would like to add something from myself.
Blocks the loading of scripts not confirmed by the attribute. (type = "text / javascript", type = "text / css")
Prohibits embed this page in an iframe
ban on downloading anything over an unencrypted protocol (HTTP)
Comment BeLove :
An important note regarding this and the previous topic is the httpOnly cookie.
This standard was introduced long ago, but is forgotten or ignored by many. He does the following: makes cookies inaccessible by means other than HTTP. Installing it means that they cannot be obtained using JavaScript.
httpOnly is the seventh parameter of the setcookie () function in PHP.
This vulnerability is manifested when the developer points to a direct link to an internal object, such as a file, directory, or database entry, as a parameter in the URL. This allows the attacker to gain unauthorized access to the system due to manipulations with this parameter.
Here it’s easier to immediately give examples:
You can’t just forget to check whether the user is facing us or not.
This also includes simple protection for the number of incorrect password attempts.
Simply put, this is an insufficiently or incorrectly configured server configuration file / PHP / ...
This includes:
Immunity will give:
Prevention - this includes setting different passwords to different areas (SSH, MySQL, backends, host panel) and regularly replacing them
. Also, the application must have a strict architecture, where everyone understands - the project should not have the following:
As a rule, this vulnerability already arises as a result of a site hack, during which data was stolen that turned out to be easily readable.
Vulnerability Test:
Example # 1: An application encrypts credit card numbers in a database using default encoding. This means that when receiving data, they can be safely decoded again. Information should be encrypted with your own methods using one public key, and so that only special backend applications can decrypt it using your private key.
Example # 2: A simple site that does not use SSL on all of its pages. It is enough for the certificate to crash somewhere once, so that the attacker could steal the session ID by monitoring data traffic.
Example # 3: Store non-saline passwords in the database.
It is recommended that you do not auto-compile such information, and do not cache pages with it.
The header implies access to certain functions of the application.
This also includes the simplest vulnerability like picking a URL for the admin panel 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 invisible types of vulnerabilities for developers. Alone, as a rule, it does not do much harm, most often the damage from it can be felt in conjunction with other vulnerabilities (XSS, invalid redirects)
In fact, this is my favorite method of hacking a site, and deserves an entire article with details, but what is it then speedran?
I will provide a link to a wonderful description of the hole on securitylab.ru
Everything is very simple here, to keep all connected parts of the project up to date, update to the latest stable versions, and not use 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 click on any links. You often met a message like “You leave our site by clicking on the link ...”, so this is nothing more than a simple defense against such vulnerabilities. An attacker can take advantage of this kind of redirects through your website to pages that please him.
For example, instead of contacts.php? Act = index / site -> contacts / index / site
Such links are easier to validate.
From the name - "click hijacking." A transparent iframe lies above the page of the attacker’s site; using the notorious social engineering, a hacker forces the user to take several specific actions. It seems to the user that he presses buttons / forms on one site, in fact, everything is adjusted so that all actions are performed on the page inside the iframe. This is achieved by creating the same coordinates of the buttons / forms on the attacking site and the victim site.
The peculiarity is that the user himself does not know that he is entering data “not there”. To prevent this, you should use the tag
A popular method is to pull the username / password from the victim. As a rule, special mailing lists are performed using special databases of victims, where users on behalf of this site are encouraged to go to the site for action.
For example, instead of yandex.ru it will be yandx.ru , uandex.ru , yandex.nk.me and so on.
Outwardly, it looks exactly like our site on which the user is logged in. Again, by any means social. an engineering attacker asks the victim to log in, (on his site), and simply receives a username / password. Typically, after entering something like an authorization error message is issued, and nothing else happens.
Even browsers and a large number of antiviruses are now protected from phishing, but the problem remains relevant. In order to avoid “rooting” of your users account, ask them to enter a password during especially important operations (money transfer), or ask to confirm your account using SMS.
Already, perhaps, an unlikely way to capture the site.
It consists in the incorrect logic of the application, allowing you to connect any file on the server (if the configuration is incorrect , again).
In the address bar we see the query:
Already clearer than clear, right? Typically, the following is inside:
Then your fantasy can play as much as you like:
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, reasons, examples and solutions will be described thesis.
Some of the vulnerabilities provided in the list have already been described more than once - a well-known fact, but without them the list would be incomplete. Therefore, I will immediately give a small post content:
- SQL injection
- Incorrect authentication and session management
- Cross Site Scripting (XSS)
- Insecure direct object references
- Unsafe configuration
- Sensitive Data Leak
- Lack of access control to the functional level
- Cross Site Request Forgery (CSRF)
- Using components with known vulnerabilities
- Invalid 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 stored in the browser cookie, unless the cookie is disabled in the browser. In this case, they will automatically be substituted into each URL by the server itself
index.php?PHPSESSID=jf843jgk4ogkfdjfgomg84o4og54mg
As you can see, the ID is transmitted in the clear, while with cookies it is hidden in the header of the HTTP request.
To do this, provide for the prohibition of sending sessions through the 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
Using encryption
If confidential information (money, wallet numbers, health status) should be stored / transmitted on your site, then it is worth using encrypted protocols with an SSL certificate.
In this case, when setting a cookie, set the sixth parameter secure = 1 .
setcookie ('example', 'content', 0, '', '', 1);
If you store the password in the $ _SESSION variable or the database, then you should not store it in the clear. It can only be a hash from it, or a scripted version.
Actually, it’s easy to steal the session ID from the URL, and it’s a little harder to do with cookies.
Ways of protection:
- Avoid sessions without cookies
- Avoid third-party server authentication solutions
- Check IP
- For particularly important actions, request the password again
- SSL certificate
- Ending sessions on time and often enough
A reliable way is to store the IP in the session, and if for some reason it suddenly starts to differ, stop displaying anything on the page, you can even forcefully end the session.
However, there are drawbacks - the cracker and the user can sit behind 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, this makes direct hijacking of cookies impossible. Less - cookies can still be stolen physically, so other protection methods are also required.
About the completion of sessions - their life should be set to a 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 quite effectively protect customers from such a hack. After all, a hacker just needs to have a session ID, and he will no longer need a password or username to appear in his image.
3. XSS
An exhaustive and wonderful article: habrahabr.ru/post/149152
... but I would like to add something from myself.
HTTP headers:
X-Content-Type-Options: nosniffBlocks the loading of scripts not confirmed by the attribute. (type = "text / javascript", type = "text / css")
X-Frame-Options: DENYProhibits embed this page in an iframe
Strict-Transport-Security: max-age=expireTimeComment BeLove :
This header tells the browser to work with the resource only via HTTPS, i.e. It is sent during 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 long ago, but is forgotten or ignored by many. He does the following: makes cookies inaccessible by means other than HTTP. Installing it means that they cannot be obtained using JavaScript.
alert(document.cookie);
httpOnly is the seventh parameter of the setcookie () function in PHP.
4. Insecure direct object references
This vulnerability is manifested when the developer points to a direct link to an internal object, such as a file, directory, or database entry, as a parameter in the URL. This allows the attacker to gain unauthorized access to the system due to manipulations with this parameter.
Here it’s easier to immediately give examples:
- Direct link to a private photo in a private album
- Open wallet number in GET request
- AJAX request-response by userID, returning all user data in JSON, which are filtered on the client side (funny, I met it myself)
- Open viewing / editing, for example, your profile. In the example below, a 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’t just forget to check whether the user is facing us or not.
This also includes simple protection for the number of incorrect password attempts.
5. Insecure configuration
Simply put, this is an insufficiently or incorrectly configured server configuration file / PHP / ...
This includes:
- Open Logs
- Non-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 a router in the office.
- Open access to images folders. Closes with .htaccess or empty index.html
- And open folders like .git or .svn
Immunity will give:
- Current versions of used software (frameworks, libs)
- Fewer modules and plugins
- Closing all kinds of executions with fatal files to avoid showing code fragments or even files responsible for a particular operation.
Prevention - this includes setting different passwords to different areas (SSH, MySQL, backends, host panel) and regularly replacing them
. 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. Sensitive data leakage
As a rule, this vulnerability already arises as a result of a site hack, during which data was stolen that turned out to be easily readable.
Vulnerability Test:
- Do we have any data about money / wallet numbers / health status in the database in an open form?
- Also, in what form is this data transmitted over the network?
- Are the latest software versions worth it?
- Is the encryption algorithm strong enough and is it updated frequently?
Example # 1: An application encrypts credit card numbers in a database using default encoding. This means that when receiving data, they can be safely decoded again. Information should be encrypted with your own methods using one public key, and so that only special backend applications can decrypt it using your private key.
Example # 2: A simple site that does not use SSL on all of its pages. It is enough for the certificate to crash somewhere once, so that the attacker could steal the session ID by monitoring data traffic.
Example # 3: Store non-saline passwords in the database.
It is recommended that you do not auto-compile such information, and do not cache pages with it.
7. Lack of access control to the functional level
The header implies access to certain functions of the application.
- Do not leave links for those who do not have permission to go there
- Immunity will give by default the removal of access for everyone and from everything - the principle of a white sheet and deny (*).
- Also, checking in important places of the code during the execution of the action will not hurt - when the function / method is called, set the check again.
This also includes the simplest vulnerability like picking a URL for the admin panel 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 invisible types of vulnerabilities for developers. Alone, as a rule, it does not do much harm, most often the damage from it can be felt in conjunction with other vulnerabilities (XSS, invalid redirects)
In fact, this is my favorite method of hacking a site, and deserves an entire article with details, but what is it then speedran?
I will provide a link to a wonderful description of the hole on securitylab.ru
9. Using components with known vulnerabilities
Everything is very simple here, to keep all connected parts of the project up to date, update to the latest stable versions, and not use less popular or amateur modules. If there is a choice - do not use them in principle.
10. Invalid redirects
The bottom line is that users trusting your site can click on any links. You often met a message like “You leave our site by clicking on the link ...”, so this is nothing more than a simple defense against such vulnerabilities. An attacker can take advantage of this kind of redirects through your website to pages that please him.
Prevention
- Do not abuse redirects.
- If necessary, do not use user data in the request (like success.php&user_mail=eeee@eee.com)
- It is recommended to rewrite urls with server tools.
For example, instead of contacts.php? Act = index / site -> contacts / index / site
Such links are easier to validate.
11. Clickjacking
From the name - "click hijacking." A transparent iframe lies above the page of the attacker’s site; using the notorious social engineering, a hacker forces the user to take several specific actions. It seems to the user that he presses buttons / forms on one site, in fact, everything is adjusted so that all actions are performed on the page inside the iframe. This is achieved by creating the same coordinates of the buttons / forms on the attacking site and the victim site.
The peculiarity is that the user himself does not know that he is entering data “not there”. To prevent this, you should use the tag
X-Frame-Options: DENY(see above) , and a simple captcha or re-enter the password.12. Phishing
A popular method is to pull the username / password from the victim. As a rule, special mailing lists are performed using special databases of victims, where users on behalf of this site are encouraged to go to the site for action.
For example, instead of yandex.ru it will be yandx.ru , uandex.ru , yandex.nk.me and so on.
Outwardly, it looks exactly like our site on which the user is logged in. Again, by any means social. an engineering attacker asks the victim to log in, (on his site), and simply receives a username / password. Typically, after entering something like an authorization error message is issued, and nothing else happens.
Even browsers and a large number of antiviruses are now protected from phishing, but the problem remains relevant. In order to avoid “rooting” of your users account, ask them to enter a password during especially important operations (money transfer), or ask to confirm your account using SMS.
13. PHP Include
Already, perhaps, an unlikely way to capture the site.
It consists in the incorrect logic of the application, allowing you to connect any file on the server (if the configuration is incorrect , again).
In the address bar we see the query:
site.com/index.php?p=contacts.phpAlready clearer than clear, right? Typically, the following is inside:
Then your fantasy can play as much as you like:
site.com/index.php?file=../../etc/passwd%00 # Из комментария redc0de: не работает с версии 5.3.4
site.com/index.php?file=../apache/error.log # Сгенерировать ошибку в запросе с
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.