A8 Failure to Restrict URL Access

Problem and Protection

WordPress allows deleted blog post o  WordPress versions 2.8 and below had a

problem o  Only the owner of a blog should see certain

posts. They remain private until he publishes them

o  But if he deleted "all-your-base-belong-to-us" then anyone could browse to "trash/all-your-base-belong-to-us" and see that article

o  They just had to know the blog title and the exploit

o  A script could detect all deleted posts and show them to anyone

Failure to restrict URL access o  Any sensitive page that is

unprotected by authorization methods is vulnerable

o  Security by obscurity doesn't work!

o  Myth: If I host a page, but don't ever provide a link to it, it won't be found by hackers

o  Reality: Yes, yes it will

How attackers do it

o  Skilled and lucky hackers will find these pages

o  Use a technique called forced browsing o  Automated tools guess links using common

folders and page names •  user/add •  admin/newuser.aspx •  web.config •  /log/ •  /password •  And on and on and on and on ...

Assume attackers will find hidden pages

o  If we have URLs like: tic.com/Customers/View/2148102445

tic.com/Customers/ViewDetails.aspx?ID=2148102445

o  Attackers will try: tic.com/Customers/Update/2148102445 tic.com/Customers/Modify.aspx?ID=2148102445

tic.com/Customers/admin

o  Developers assume that if we don't provide a link to these resources, the bad guys won't know they're present

o  They always find out

How we protect ourselves

o  Require authentication on all sensitive pages o  Do the same for non-pages o  Use role-based authentication as much as

possible o  Use negative permissions o  Enforce security on both the client and the

server o  Check before every sensitive operation

Protect all sensitive pages

o  Looking at your application, make a list of every page that can be accessed

o  Ask yourself: •  Is this page sensitive? •  If so, how should it be protected by

authentication and authorization? •  Is it?

o  If it isn't protected as it should be, make it so

Protect things that aren't pages o  Don't forget about: o  AJAX methods o  Web services & methods o  Configuration files

•  web.config •  global.asax •  database files (*.mdf, *.mdb) •  Hibernate.xml •  SiteMap.xml

o  Version control files •  *svn •  *git*

o  Source code files •  *.vb •  *.cs •  *.php •  *.pl •  All these should be stored outside the web's root folder

Use roles

o  When possible, use role-based authentication and authorization

o  Makes it easier to manage •  Therefore we're more likely to actually do it

Use negative permissions

o  Many sites deny you if you match certain criteria

o  We should do the opposite: •  deny all permissions to sensitive pages and only

grant access if certain criteria is met o  Example:

•  Don't do this: if (Web.Security.Identity.Role == "user")

throw new SecurityException("Denied");

•  Do this instead: if (Web.Security.Identity.Role != "admin")

throw new SecurityException("Denied");

Security on both client and server

o  Some of us make the mistake that if we're enforcing security on the browser through:

― Menus ― Login screens, ― Hidden or non-rendered controls

... then those pages are protected o  Not true o  Go back in and enforce security on the

server side for all those assets

Check before every operation

o  Sometimes we have a login page at the start of a process and then assume that if they get past that, all subsequent pages are protected

o  An attacker will simply bypass the login page and go right to the resource

o  This is not possible with some frameworks such as the .Net security provider

Summary

o  Don't forget that attackers can directly type in the URLs of pages and other assets on your site

o  Hoping that they won't be discovered is poor protection (security by obscurity)

o  To protect ourselves, we should •  Require authentication on all sensitive pages and

other assets •  Check negative permissions before every

sensitive operation •  Enforce security on both the client and the server

Further study

o  Nikto2, a tool which detects unprotected pages: •  http://www.cirt.net/nikto2

o  Testing for path traversal: o  http://bit.ly/PathTraversal

o  WordPress vulnerability and Python script: o  http://bit.ly/WordpressVulnerability