funcptr - security

Change one password

2018-12-24T06:19:52+00:00

It is that time of year where security professionals the world over end up talking with friends and family about security. It will be inevitable, almost as inevitable as someone wearing a stupid Christmas sweater they are a little too proud of.

The standard advice we've been giving for years is pretty simple:

Don't re-use your passwords across sites</li>
Use a password manager</li> </ol>
Anyone that has done technical support for anyone that isn't as familiar with IT knows well that as soon as you complicate something, you end up getting twice the calls, even for things that are not your fault; "Well, since you setup that password thing my printer won't print" ...
It is fantastic advice, it is where we should all strive to be, we should all have password managers and should never re-use passwords.
However let's change one single password. Start small.
There is likely to be a single account that is the root of trust for all other accounts. An email address, either at an ISP somewhere (and maybe this is the year you get them to switch from that old Earthlink</a> email address?) or more likely a free email provider.
That's the account we want to target.
If we can secure the root of trust, the email address that can be used for password reset emails and for phishing we've already won a large battle. Individual accounts may still be "vulnerable", but now we've closed one giant hole.
After all, we all learn to walk before we learn how to run. This small step can set the tone for even more and better security later.
Should we go further? Absolutely, identify the primary accounts that are high risk, as an example:



Tamper proof session cookies and session storage
2014-06-10T17:09:45+00:00
As a follow-up to my previous article regarding User sessions, what data
should be stored where?</a>, I wanted to discuss how to store the session, and
how to generate cookies that are tamper proof.</p>
What are we trying to accomplish?</h2>
Ultimately we want to be able to have X amount pieces of data that are tied to
a particular user. Unfortunately due the fact that HTTP is a stateless protocol
we have to use cookies. Cookies are small little pieces of data that are
transmitted from the server to the client (generally done once), and then upon
the user coming back to the website they are transmitted from the client to the
server. This allows us to uniquely track a single user across connections to
our website.</p>
If the website allows a user to authenticate and the fact that they are
authenticated is stored in the session, we also want to make sure that we can
aggressively expire a session, if this is possible depends on our session
storage.</p>
Session storage</h2>
There are a multitude of ways to store the session data, but it ultimately
boils down to server-side or client-side. Server-side can be done in Cassandra,
Memcache, Redis or even in a SQL database.</p>
Server-side storage</h3>
The main one that has
been used for years is to use server side storage. Storing a small file on the
servers hard drive that contains the data, and the client is sent a cookie that
contains a unique identifier that is linked to the on-disk storage.</p>
For example:</p>
1 => /tmp/session_1</span></span>
2 => /tmp/session_2</span></span>
...</span></span>
N => /tmp/session_N</span></span></code></pre>Easily expire sessions</h4>
The upside to server-side storage is that it is possible for us to very easily
expire a session, simply remove the associated file/data that is stored and the
users session has now become invalid.</p>
Client-side storage</h3>
The other method that has recently started being used more to make it easier to
scale the server side is to store session data encoded in base64 in the cookie
itself. In this case there is no unique session ID, and no data is stored
server side.</p>
Expiration is more difficult</h4>
The downside to using client-side storage is that there is no way, short of the
expiration on the cookie itself for the website to expire a session. There are
work-arounds, but they all require storing state server-side. A hybrid approach
for example is possible, store a unique ID along with the session data, and
store that unique ID server side, but none of the extra data. Remove the unique
ID server side and if we receive a session that contains a unique ID we don't
recognise, we simply clear the session.</p>
Expiration, why do I care?</h2>
Being able to easily expire a users sessions allows for extra security
measures. For example in Google Mail it is possible to sign out all other
locations, this forces those other locations to re-authenticate before gaining
access to your account.</p>
This is a good security measure to have, so that if a users cookie is stolen,
or their credentials are compromised upon changing their password all their
sessions are invalidated and an attacker using an old cookie/session ID can't
continue to wreak havoc on the users account.</p>
Cookie format</h2>
If we are just storing a session ID, or the full session the cookie should be
hardened so that it can not be tampered with by a client. Even if you are
protecting the cookie using SSL, we still don't want to allow a malicious user
to modify the cookie to change the session ID or the session itself.</p>
Signing your cookie</h3>
The single best way to make sure your cookie has not been tampered with is to
cryptographically sign your cookie, and upon receiving the cookie from the
client verifying that the signature matches what you are expecting. This is
especially important if you are using client-side storage, because you don't
want someone to be able to change the user ID from 950 to 1 and suddenly
impersonate a different user.</p>
Use an HMAC</h4>
HMAC (Hash-based message authentication code) is an cryptographic construct
that uses a hashing algorithm (SHA-1, SHA-256, SHA-3) to create a MAC (message
authentication code) with a secret key. It is very easy given the secret key
and the original data to create the MAC, but it is very difficult if not
impossible to take the original data, and MAC and get the secret key.</p>
This allows us to do the following:</p>
data = "Hello World"</span></span>
mac = HMAC(data, sha256, "SEEKRIT")</span></span></code></pre>
Our mac</code> would now be equal to:</p>
e655f98cb9b3c02f45576f7906d64b0b7f8731f25a5319c42ca666917aca45a4</span></span></code></pre>
If we now create our cookie as follows:</p>
cookie = mac + " " + data</span></span></code></pre>
It would look as follows:</p>
cookie = e655f98cb9b3c02f45576f7906d64b0b7f8731f25a5319c42ca666917aca45a4 Hello World</span></span></code></pre>
We can then send that to the client that requested the page. Once the client
visits the next page, their browser will send that same cookie back to use. If
we split the mac from the data, we can then do the following operation:</p>
cookie = e655f98cb9b3c02f45576f7906d64b0b7f8731f25a5319c42ca666917aca45a4 Hello World</span></span>
data = "Hello World"</span></span>
mac = e655f98cb9b3c02f45576f7906d64b0b7f8731f25a5319c42ca666917aca45a4</span></span>
</span>
mac_verify = HMAC(data, sha256, "SEEKRIT")</span></span>
</span>
mac_verify == mac</span></span></code></pre>
If and only if mac_verify</code> and mac</code> are the same can we be sure that the
cookie has not been tampered with.</p>
This requires that the client is NEVER aware of what we are using as our secret
key. In the above exmaples that is "SEEKRIT". In your web application you will
be required to make this a configuration variable, and you will have to take
care not to commit that configuration variable to a git repository and upload
it to github (for example).</p>
Do not use a bare hash algorithm</h4>
Using a bare hash algorithm allows for length extension attacks</a> if used
incorrectly, this would allow an attacker to concatenate extra data to the end
of our existing data, modify the "MAC" and the server would accept it.</p>
This construct is thus very dangerous:</p>
data = "Hello World"</span></span>
key = "SEEKRIT"</span></span>
mac = SHA1(key + data)</span></span></code></pre>
The following construct is still not recommended, but is not nearly as
dangerous:</p>
mac = SHA1(data + key)</span></span></code></pre>
Due to the key being last, this is not vulnerable to a length extension attack,
however please don't do this, instead stick to using an HMAC instead.</p>
Encrypting session data</h2>
When using client-side storage, it may be beneficial to encrypt the data to add
an extra layer of security. Even if encrypting the data you need to continue
using a MAC.</p>
Using just encryption will not protect you against decrypting bad data because
an attacker decided to provide invalid data. Signing the cookie data with a MAC
makes sure that the attacker is not able to mess with the ciphertext.</p>
What are web frameworks/languages doing by default?</h2>
I am most familiar with the Pylons Project's Pyramid Web Framework</a>, the
default session implementation that is provided by the project is named
SignedCookieSessionFactory</code>, as the name implies this uses a client-side
cookie to store the session data, which is signed using a secret key that is
provided upon instantiation of the factory.</p>
Flask sessions</a> also uses a signed cookie for client-side session storage.</p>
Ruby on Rails</a> uses a signed/encrypted cookie for client-side session
storage by default.</p>
PHP</a> does not by default sign the session cookie, it does however use
server-side storage for session data by default. However extra security can be
added by installing PHP SuHoSin</a> which adds session cookie
encryption/signing.</p>


User sessions, what data should be stored where?
2013-08-25T13:05:00+00:00
This article has been updated. For the old version please check
Archive.org</a></em></p>
A couple of days ago on reddit.com</a>'s /r/netsec</a> a poster by the name
of Dan Weber</a> posted what he believed to be an attack on PHP sessions:
Hacking PHP sessions by running out of memory</a> (reddit link)</a>. The way
the "attack" works is as follows:</p>

Create a new session</li>
Assign some new data to the session, in this case a username which is used
to signify that the user is logged in.</li>
Check to verify that the user should be logged in</li>
If the user should not be logged in, destroy the session.</li>
</ol>
The "attack" would be to run the PHP</a> script out of memory on number 3, since
once something is set on the session it is immediately stored, so even if the
user is not supposed to be logged in, they are now logged in since their
session says they are.</p>
I wouldn't necessarily call this a PHP hack, this is really just bad practice
in terms of programming, the logic should be reversed.</p>

Create a new session</li>
Verify the user should be logged in</li>
If so, set the session data</li>
If the user should not be logged in, don't set the session data</li>
</ol>
That would solve the problem at hand, and now there is no way for the user to
trick the PHP script into believing she is logged in when that is not the case.</p>
However as the discussion went on on Reddit, it became even more clear that
there are no good resources on what you should store in the user session, and
what you shouldn't store in the user session. Some of these things may seem
like common knowledge, but sadly this is something every single new person to
programming has to learn on their own.</p>
Some assumptions</h2>
Let's get this out of the way, this is in no way limited to PHP, but it is the
one I will be using as an example. This can all apply to Ruby (Ruby on
Rails</a>), Python (Pyramid</a>) or many other frameworks.</p>
The basic problem is that generally writing to the session is not an atomic
transaction based on the page accessed, so the assumption made in this article
is that when you write to the session it is instantly committed, and there is
no way to roll it back upon failure. If there was, our first example listed
wouldn't be able to occur since upon running out of memory at step 3, the
session would have been rolled back and cleaned up.</p>
What should you store in the users session?</h2>
You should only really store anything in the session that if it were made
public it would do very little harm.</p>
Really the list of items to be stored in a session are as follows:</p>

The users unique id (The ID that allows you to retrieve the users
information from storage)</li>
Temporary state (i.e. Flash messages)</li>
CSRF token</li>
</ol>
More importantly, don't store permission bits, or group memberships, or
anything that is used to allow/deny access to particular resources. You want to
store just enough information that upon a user accessing your site you are able
to retrieve the users information from storage, and based upon that information
from storage you then make decisions such as permissions/group memberships.</p>
Why is this important?</h3>
One of the things that Dan Weber brought up in the Reddit post was storing the
users permission level and group membership in the session. If your code is
then relying on the session to always contain the right permission level, then
there is no way to expire someones access to the data.</p>

A user logs in</li>
A user gets various permissions, and they are set in the session</li>
The user has been fired from his job, and an administrator removes the
users permissions</li>
Since the user is still logged in, the users permission bits are still
set, and he continues to have access to parts of the site/information he
shouldn't have access to.</li>
</ol>
If instead on every page visit we simply pull out the users unique id and
verify the permissions upon access, as soon as the permissions are revoked by
the administrator the user no longer has access to the various resources.</p>
Temporary state</h3>
There has to be an easy way to remember something from page visit to page visit
that isn't considered detrimental if the information gets lost. One of those
things is flash messages. Flash messages are generally used to provide the user
indication that something has changed, they are shown once and then never
again.</p>
Storing these as session data makes sense. If the flash message gets set,
great, if it doesn't get set, it doesn't matter. Flash messages are simply a
notification tool, if the user misses them it isn't important.</p>
What you shouldn't store in the session</h2>
Definitely don't store any kind of permission bits, groups a user is a part of
or anything that would allow the user access that they normally would not be
able to access.</p>
On each page access check what permissions the user has. While it may mean a
little more heavy lifting server side it provides extra security, and the means
to enforce changes in permissions instantly.</p>
Good secure programming practices</h2>
Keep secure programming practices in mind at all times, always consider how the
information you are storing/processing is accessed/viewed/administered. More
importantly think about the access controls that are in place, and how one
could expire access to a particular resource without requiring a co-operative
client.</p>
The ordering of how variables are set, and when they are set are very
important.  $_SESSION['isadmin'] = True</code> at the top of a PHP script, and then
removing it by checking to see if the user is actually an administrator later
on in the script is a bad idea.</p>
Always order your code so that if a failure does occur there is no chance that
a critical section of your code is executed by accident, or that information is
stored in a half-verified state. This is especially important for access
control.</p>

funcptr - security

Change one password

Tamper proof session cookies and session storage

Session storage</h2> There are a multitude of ways to store the session data, but it ultimately boils down to server-side or client-side. Server-side can be done in Cassandra, Memcache, Redis or even in a SQL database.</p>

Server-side storage</h3> The main one that has been used for years is to use server side storage. Storing a small file on the servers hard drive that contains the data, and the client is sent a cookie that contains a unique identifier that is linked to the on-disk storage.</p> For example:</p>

Easily expire sessions</h4> The upside to server-side storage is that it is possible for us to very easily expire a session, simply remove the associated file/data that is stored and the users session has now become invalid.</p>

Client-side storage</h3> The other method that has recently started being used more to make it easier to scale the server side is to store session data encoded in base64 in the cookie itself. In this case there is no unique session ID, and no data is stored server side.</p>

User sessions, what data should be stored where?

Session storage</h2>
There are a multitude of ways to store the session data, but it ultimately boils down to server-side or client-side. Server-side can be done in Cassandra, Memcache, Redis or even in a SQL database.</p>

Easily expire sessions</h4>
The upside to server-side storage is that it is possible for us to very easily expire a session, simply remove the associated file/data that is stored and the users session has now become invalid.</p>

Client-side storage</h3>
The other method that has recently started being used more to make it easier to scale the server side is to store session data encoded in base64 in the cookie itself. In this case there is no unique session ID, and no data is stored server side.</p>