A2--Broken Access Control





A2– Broken Access Control

This section correlates to 2.2 of the WASC Threat Classifications.

Determining if access control violations are possible against a target is a subjective endeavor because all Web apps do not implement access control in the same manner. Access control mechanisms place restrictions on what users are allowed to do based on who they are. Virtually all modern-day business-related Web apps have some access control requirements. Therefore, an access control policy should be clearly documented, and that is what you need to work with. The policy is what you can test against and verify that it is properly enforced throughout the app the way it was intended based on the policy. Chances are that if this documentation does not exist, the target will have areas of unnecessary risk.

If there is an access control policy, there must be code that enforces it. One option for checking this is a code audit with the goal of verification of the access control implementation. Another option is using scripts similar to the resource enumeration Perl script from Chapter 3. Based on the policy, or even blind, that script can be modified to run through the target and spit out HTTP Response codes. So for example, if the target app utilizes HTTP Basic Auth across the board, and you get status 200 responses from a certain set of directories, then that warrants further investigation; chances are there is some broken access control.

If there is the possibility of gaining some knowledge about the target, administration of the app and content management/publishing are two areas where you want to do some analysis. You want to concentrate on the following as a starting point:

  • How is the app administrated? By how many people? And what gives them that right above regular app users?

  • How are changes made to content? How are these changes published to production?

  • How many people have publishing rights? How are those rights determined, established, and enforced?

  • Is there a QA testing and verification process for content?

  • How are changes made to the app? How are these changes published to production?

  • How many people can touch the app to publish new or updated code? Are they developers? How are those rights determined, established, and enforced?

  • Is there a QA testing and verification process for app modifications?

  • Is any of the publishing or deploying done remotely? If so, how?

  • How is the DB maintained and administrated? By how many people? Do the DBAs have remote access to the DB server(s)?

  • Is the app segmented by access control or is there one blanket group with publishing rights?

Carefully review each interface to make sure that only authorized personnel are allowed access to the appropriate sections. Also ensure that only authorized data can be touched — typically a blanket policy covering all users who can change data is not a good idea.

Previous Section
Next Section


 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows