Attacking Acls

Now that we know what the authorization data is and where it sits, we can ask, " How is it commonly attacked ?"

We discuss ACL attacks first because they are the " lowest common denominator" of web application authz: all web applications to some degree rely on resource ACLs for protection, whereas not all web apps implement access/session tokens (many apps achieve essentially the same effect via local account impersonation). Put another way, ACL attacks are the most simplistic, while attacking authz/session tokens often involves much more work. The earliest and easiest web app compromises are thus usually related to weak ACLs.

As noted in Chapter 1, the relatively straightforward syntax of the URI makes it really easy to craft arbitrary resource requests , some of which may illuminate hidden authorization boundaries or bypass them altogether. We'll discuss some of the most commonly-used URI manipulation techniques for achieving this next .

Directory Traversal

Directory traversal is considered the canonical (no pun intended) example of bypassing web directory, or folder, permissions. A classic web directory authorization attack is the "dot-dot-slash," which uses the common file system notation of "../" for "move to the directory above the current one." One of the best examples of this was the well-publicized Unicode and Double Decode directory traversal attacks for IIS in 2001, which took advantage of a weakness in IIS' parsing and authorization engine. The Unicode variant of this vulnerability was exploited as follows . Normally, IIS blocks attempts to escape the web document root with dot-dot-slash URLs such as "/scripts/../../../../winnt". The Unicode representation for the slash (/) is "%c0%af". However, due to the bug, IIS did not fully decode (canonicalize) the Unicode representation until after its authorization check, which allowed a malicious user to access objects outside the document root with a URL such as "/scripts/ ..%c0%af..%c0%af..%c0%afwinnt".

"Hidden" Resources

Careful profiling of the application (see Chapter 2) can also reveal patterns in the naming convention for the application's folders and files. For example, if a /user/menu directory exists, perhaps an /admin/menu exists as well, relying on simple obscurity to protect its administration front end. This makes directory name -guessing a profitable way to dig up "hidden" portions of a site, which can be used to seed further ACL footprinting, as we mentioned earlier.

Such "security through obscurity" usually yields to even the most trivial tampering. For example, by simply modifying the object name in the URL, a hacker can sometimes retrieve files that they would not normally be able to access. A site may display a link to http://www. reports .com/data/report1234 5 .txt, after you pay for access to that report. A meddlesome hacker might attempt to access http://www.reports.com/data/report1234 6 .txt to see what happened , and might possibly be rewarded with the contents of report123456.txt.

Another example of bypassing authorization via URL tampering is the Cisco IOS HTTP Authorization vulnerability. The URL of the web-based administration interface contains a two-digit number between 16 and 99.

 http://www.victim.com/level/  NN  /exec/... 

By guessing the value of NN (the two-digit number), it is possible to bypass authorization and access the device's administration interface at the highest privilege.

Custom application naming conventions can also give hints about hidden directory names . For example, maybe the application profile (see Chapter 2) did not reveal any "secret" or administration directoriesbut you notice that the application uses "sec" in front of variables (secPass) and some pages (secMenu.html). What if you tried looking for "/ secadmin" instead of "/admin"?

Tip 

Common "hidden" web application resources frequently targeted by path -guessing attacks are listed in Chapter 10.