Tuesday, 23 July 2013

Don't go live with simple security problems - 10 tips to help

I feel anger when I stumble across very, very, very simple security issues. Especially when they compromise my data.

Yes I do. And I hope, as a tester, that you do too.

But I face a problem... As a tester, I can't say "Did no-one test this!" because I know that they might have done, and someone else might have chosen to go live anyway.

But on the off chance that no-one did 'test this', I offer you this post.

Security by obscurity


If I visit your site and I can gain access to top level pages that I shouldn't have, then I get angry, because that should never happen.

Even if you haven't told me about the URL, I can try to guess it from your other naming conventions.

Please make sure you secure your URLs.
Security by obscurity doesn't work for very long.

 

Validate Parameters on the server


And if I see parameters in your URLs. I'll change them.

Yes I will.

I will:
  • Because I don't want the list of items to stay limited at 25, I want to see 2500
    • No I don't care about the performance impact on your database - fix that a different way
  • Because I want to skip ahead more pages than you have listed on the page. "I want to go to page 15 now!"
    • No I don't care about the user experience you want me to have, I care about the user experience that I want to have
  • Because I can
    • Yes, because I can

 

Security by ignorance


When I visit your site, I look at the traffic you issue when I hit a top level URL.

I look at what requests you make to build the page.

Yes I do.

Most browsers have the functionality to view traffic built in now. Any user can view the traffic and see the URLs that you access.

And then I use that information...

I take the URLs you've used. And I use them.

Sometimes I change them. Simple idea, but sadly all too effective.
  • So if you access  
    • http://site/api/123456/report  (note: not a real domain)
  • I'll access 
    • http://site/api/123455/report  (note: I changed the number)
Yes I will.

And if you haven't locked down the API to specific users, with specific role level controls. Then I'll probably see another user's report. Then I get annoyed, because as a user it means that other people can see my reports. And I don't like that.

No I don't.
Assume that anything you do automatically someone else will do manually.
Just because they can.


Make sure you have low level permissions on your API, don't assume that no-one will notice it.

I frequently do this because I want to bypass the horrendous GUIs that web sites put in my face, when I want to achieve a result, rather than experience your broken GUI. So I script it. Or if I can get away by posting a URL with some data, then I'll do it.

I bet other people do this too.

Testers should do this too, because...
Security by ignorance doesn't work.

 

Security through sequential numbering


And if you're using sequential IDs for reports, or users, or accounts, etc. you actively encouraged people to hack you.

Yes you did.

No-one has ever recommended - Security through Sequential numbering.

No they haven't. Never Ever.
Security through sequential numbering doesn't work.

 

Tips for Testing


So now, the inevitable 10 tips for testing:
  1. Play with the URLs
  2. Change URL Parameters
    1. to check that permissions surround the public level
    2. to check that request validation takes place
  3. Try URLs when logged out to make sure permissions apply
  4. Guess some URLs
  5. Use an HTTP Debug proxy and look at the traffic
  6. Investigate the traffic and see what the requests do
  7. Issue the traffic requests out of context on a page to understand the 'real' state rules in place
  8. Change the URL parameters  in the traffic URLs
    1. to check that permissions surround the AP
    2.  to check that request validation acts at the API level, not just the GUI level
  9. Issue the requests when logged out to check the permissions still apply
  10. And if you do test like this, and your organisation keeps ignoring these types of defects, check if you reported them effectively, and if you did, then leave because that company doesn't deserve you.

 

You wouldn't like me when I'm Angry


I didn't even describe security testing above. I described functionality testing.

And really basic functionality testing at that, just simple input variations. I haven't messed with cookies, I haven't done anything hard (because cookie editing ain't easy, 'right kids).

If you don't include this "really really simple stuff" level of test activity, then please let me know so that I can avoid your site and find a competitor quickly before we develop a user/supplier relationship.

I really don't like getting angry when I act as a user.

Trust me, you wouldn't want me as an Angry user.

PS:
  • Yes, this blog post does describe problems found at a specific web site.
  • No I will not name that site.
  • Yes, I have already told them... and more than once.
  • Yes I have started looking at alternatives, sigh.

4 comments:

  1. But no user would ever do that!

    :-)

    Nice article!

    ReplyDelete
  2. I just scanned through 40 (excact number)of my most recent testing blog articles in my RSS feed to find this.

    Before this article I was beginning to get annoyed at the lack of education in articles people were writting.

    So thanks Alan, it's good to see someone promoting good testing and giving advice to others still.

    Very well written and an enjoyable read!

    ReplyDelete