07 a8 failure to restrict url access.pptx
DESCRIPTION
Part of the Web Application Security CourseTRANSCRIPT
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