I often stumble across security issues on live sites. Some are very simple. Here are some tips to use to help you find simple security issues before they go live.
Security by obscurity
If there is a url people are not supposed to be able to access then secure it, and automate the continued assertion that the access control exists.
Even if you haven’t told me about the URL, I may be able guess Urls from your other naming conventions.
Secure your URLs.
Security by obscurity doesn’t work for very long.
Validate Parameters on the server
If I see parameters in your URLs. I’ll change them.
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
- 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
- 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.
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)
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.
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.
Be careful with API access from JavaScript. API permissions are essential for JavaScript access because the ‘secret auth codes’ are visible in cient side calls.
I recently tried and failed to draw attention to a website for API usage. They had embedded an API Auth code in the XHR request headers. Which I could use to access their API directly. The API told me I had POST, PATCH, DELETE permissions. I didn’t try that, so I don’t know if I did. The site itself didn’t respond to me when I raised it. They might still be vulnerable.
Testers should do this too, because…
Security by ignorance doesn’t work.
Security through sequential numbering
If you’re using sequential IDs for reports, or users, or accounts, etc. you actively encouraged people to hack you.
No-one has ever recommended - Security through Sequential numbering.
Security through sequential numbering doesn’t work.
Tips for Testing
10 tips for simple security testing:
- Play with the URLs
- Change URL Parameters
- to check that permissions surround the public level
- to check that request validation takes place
- Try URLs when logged out to make sure permissions apply
- Guess some URLs
- Use an HTTP Debug proxy and look at the traffic
- Investigate the traffic and see what the requests do
- Issue the traffic requests out of context on a page to understand the ‘real’ state rules in place
- Change the URL parameters in the traffic URLs
- to check that permissions surround the AP
- to check that request validation acts at the API level, not just the GUI level
- Issue the requests when logged out to check the permissions still apply
- 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.
Functional / Security Overlap
I didn’t really describe security testing above. I described functionality testing.
And really basic functionality testing at that, just simple input variations. I didn’t even mention messing with cookies or local storage. (But check them too.)
