CODEWITHSUNDEEP
phpsecuritypostyiiget
Igor Savinkin
Igor Savinkin

Reputation: 6277

Security issue when sending auth credentials as GET parameters

I do some authentication of user by sending him direct link with his login/password so that he is able to press it and get log in by GET parameters in URL.

Ex.: http://example.com/index.php?r=site/login&p=password&email=igor.savinkin%40gexample.com

My question is about the security issue. What if someone has put a web sniffer in parallel to the internet line thus copying the credentials or reaching cached data? I use the Yii framework, so it's quite good for security maintaining; the logging in is initially done thru POST parameters. What i've heard about POST vs GET requests:

Upvotes: 2

Views: 362

Answers (5)

SilverlightFox
SilverlightFox

Reputation: 33538

You should use a time limited token rather than sending the password in the URL. e.g.

www.example.com?token=1234567890

where token is a cryptographically secure pseudorandom number or sequence.

Upon following the link, the user will be required to set their own password before being allowed to use the rest of the system. Once the user has set their own password, the token should be expired so it cannot be used again.

As the token is time limited, there is less risk associated with sensitive data being stored anywhere the URL has been written to (e.g. if the email is left unopened in the user's mailbox). GET requests have the following risks associated with them as parameters are transmitted in the URL whereas POST requests have these in the request body:

  • The URL is logged by default on servers, appliances and proxies in between the user's browser and the system.
  • The URL is available in browser history.
  • The URL can be leaked via the referer HTTP header.

The risk can be reduced by using HTTPS. Even though the GET parameters are still visible, they are not visible by anything that cannot decrypt the SSL connection (e.g. the GET parameters are not visible to ISPs, MITMs and to non-corporate proxy servers).

There is not a huge risk associated to sending account setup links in this way, more and more email providers are encrypting their email whilst in transit to each other, and many providers allow email to be retrieved over SSL. It is this section of the journey, from the user's mailbox to their device or browser which carries the biggest risk of MITM attacks (think hacker in a coffee shop connected to wifi). However, for high security systems (e.g. banking) then this type of account activation email is not acceptable.

Upvotes: 0

darkheir
darkheir

Reputation: 8950

Don't use the password in the url!

It's really bad, anyone sniffing (or monitoring) the traffic can get the password. Plus, anyone having access to the email inbox will know the password.

An alternative would be to use a token that is valid only one time. Before sending the mail you generate a unique token that you link with the user email adress.

You will have an url like this

http://hostname.com/index.php?r=site/login&token=544a0a62e280e3.83969641&email=igor.savinkin%40gmail.com

And when the user uses the url you

  • Check that the token provided is linked with the givn adress in your DB
  • Discard the token to ensure that no one will use the same url to log in.

After the best would be to not provides any way to login using a given url. Because I assume that you'll send the link by email, and the SMTP protocol is not secured.

Upvotes: 3

ConroyP
ConroyP

Reputation: 41926

Sending the password as a GET param increases the number of places a malicious individual could learn that password:

  • the network sniffing you mentioned
  • if an attacker gets in to that user's email, they'll then find the login details to your service also
  • if the user is behind a proxy, that proxy's administrator can see the password in their logs
  • similarly, anyone who can view the access logs on your site can also potentially get at the password

An alternative is to send a time-limited token for login. Rather than sending username and password, you send a link with a token to the user which expires after a short period of time.

At it's simplest form, this token is a hashed combination of the user's credentials, the desired expiry time, and a secret token known only to your server (this last bit prevents an attacker from re-generating tokens with longer lifespans). As you'll likely be using a one-way hash function, it won't be possible to decode it when the user clicks the link, so you also send the id and expiry time to help your server determine validity when the user clicks the link.

So, where you currently generate the email for the user, you'd call a function something like the below.

// When should this token expire? $expiryTimestamp = strtotime("+3 hours"); $mySecret = "some secret phrase here"; $token = md5($userId . $expiryTimestamp . $mySecret); // Put them together to build the link $params = array( 'token' => $token, 'userId' => $userId, 'expiry' => $expiryTimestamp ); $link = '/site/login?' . http_build_query($params);

Then, when the user clicks the link, you could check it like below on your server. if ($_REQUEST['token] == md5($_REQUEST['userId'] . $_REQUEST['expiry'] . $mySecret)) { // User is good to go and within the timeframe, let them in } else { // Something not matching here, don't log them in }

Upvotes: 1

Peter
Peter

Reputation: 9123

It is very insecure to pass user credentials like this. If you would want this, then I would at least encrypt the username and password and decrypt them later on.

I wrote a little class some time ago that'll help you do this. You can find it on github. https://github.com/peterurk/cipher

Upvotes: 1

deceze
deceze

Reputation: 522195

Such URLs may be widely cached, saved or otherwise be visible:

  • if sent through email, the password is going out in cleartext over the wire, because emails are virtually always in the clear
  • the mail provider will have a copy of it on their hard drive
  • the URL will be stored, likely in the clear, somewhere on the user's hard disk
  • the browser will remember the URL in the history, in the clear
  • with a little (un)luck, the URL may even leak into Google's index

A URL has a lot of opportunity to receive a lot of exposure, that's its main issue. POST requests are by definition ephemeral and not stored permanently by compliant clients (you can't even "send" someone a POST request via email or such to begin with).

Upvotes: 3

Related Questions