Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm working on a small side project in PHP. I may yet include some sort of actual username/password registration down the line, but for now, for ease of attracting attention, my goal is to allow for any anonymous user to use my site without registering. Here's how it works, in general:

  1. User goes to the site, and creates a "thing"
  2. In the response of create.php, user is given a randomly-generated string. This is not stored on the server, but its hash is.
  3. The "success" page uses Javascript localStorage to store the string generated.
  4. In the future, if the user wishes to make small changes to their "thing", they fill out a form on a page. Then, the request is sent with this localStorage string. On serverside, it is validated against the hash before updating the thing.
  5. Someday when I implement usernames/passwords, users can visit a page to gain ownership of their items by grabbing all their localStorage values.

A few things to think about:

I've been reading up on XSS vulnerabilities used to steal cookie session IDs and similar information. The common trait with a lot of them it seems is that the bad guy is able to run Javascript on the target domain, which seems like a big assumption to me. Needless to say, I don't use eval(), and even try to avoid innerHtml whenever possible. I'm especially aware of any times that user-generated strings are put to use. I think I'm helped by the fact that my site is not especially complex or user-customizable.

I know of the HttpOnly header, but I like Javascript, and I want a lot of my site's actions to be asynchronous (so you can save a form's information without loading a new page)

Also, I should note that the information saved on my site is best labelled as entertainment, and in its proper intent, should not contain sensitive information, even so much as E-mail addresses (those would come when I implement usernames/passwords) so I think I'm fine with someone being able to break in by physical access (ie, stealing a user's laptop); I'm basically trying to find the right balance of security to convenience.

I'm also now considering that, depending on how costly it is to get a certificate, HTTPS would be important enough to include. I guess I would just be surprised at someone watching HTTP packets just to take ownership of someone else's "thing".

share|improve this question
add comment

1 Answer

up vote 2 down vote accepted

Seems to me to be a reasonably secure approach in lieu of having user accounts and session management. HTTPS is a must but I'd also look at the following points to address your specific issues.

In the response of create.php, user is given a randomly-generated string. This is not stored on the server, but its hash is.

Make sure the generated string is generated using a cryptographically secure mechanism. e.g. openssl_random_pseudo_bytes

If you want to add extra security you could add a salt, or better still use bcrypt for the server stored value.

I know of the HttpOnly header, but I like Javascript, and I want a lot of my site's actions to be asynchronous (so you can save a form's information without loading a new page)

You could use a cookie with HttpOnly set - the cookie will still be sent with your AJAX requests, it will only be the JavaScript itself that won't be able to access it. Also set the secure flag and use this in conjuction with HTTPS to make sure your cookie is only transmitted over a secure connection.

The common trait with a lot of them it seems is that the bad guy is able to run Javascript on the target domain, which seems like a big assumption to me.

That is in fact the definition of XSS in that an attacker can run JavaScript on the target domain. Make sure you're following the advice in the XSS (Cross Site Scripting) Prevention Cheat Sheet

share|improve this answer
    
To clarify what I mean by "running Javascript on the target domain" - I know that anyone can come there and open the developer tools. What I mean is, it seems like they assume that an anonymous victim could visit my page, and be given Javascript by an attacker that steals their information. That could be the case with, say, a comments-field hack, but not on a highly-controlled page. Also, any reason why the openssl_etc function wouldn't exist on my server? –  Katana314 Aug 21 '13 at 13:23
    
Additionally, there is a more concerning problem with using cookies - If it takes me more than a couple of months to implement a secure Username system (or people put it off) then daily events could certainly cause someone to clear their cookies. From what I understand, localStorage is more likely (still not 100% certain) to stick around. Also, if someone creates 20 "things" their cookies would not become overbloated with unnecessary information, even when only sent on secure requests. –  Katana314 Aug 21 '13 at 13:26
    
Yes, a XSS vulnerability means just that. An attacker via their own domain e.g. evil.com has redirected the victim by a link containing script code in the payload to your domain (e.g. a query string parameter). If your site does not sanitise the parameter before it is output, the script could run in the context of your domain. I was suggesting to test your site to ensure it wasn't vulnerable. –  SilverlightFox Aug 21 '13 at 13:29
    
Ah; that is very different from what I had expected. I will definitely make sure I look through the other XSS suggestions as well; some of them were just a bit unclear on what security would had already been broken, if any. –  Katana314 Aug 21 '13 at 13:31
    
Not sure re: openssl_etc, my point was to make sure that the random sequence was unpredictable by using a cryptographically secure algorithm. If someone clears their cookies, that's their choice at the end of the day and can't expect a server to maintain state on them. To prevent cookie bloating, you could simply have a single cookie that links a web browser to all of their 'things' (one to many relationship). –  SilverlightFox Aug 21 '13 at 13:33
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.