Authorization Best Practices

Whew! We've covered a lot of web app authorization attacks. How to mitigate all those techniques?

In this chapter, we basically divided up web app authorization attacks into two camps: server-side ACL attacks and client-side token attacks. Thus, our discussion of countermeasures is divided into two parts based on those categories.

Before we begin, some general authz best practices should be enumerated. As we've seen throughout this chapter, authz exploits are often enabled or exaggerated by web server vulnerabilities (see Chapters 3 and 10), input validation (Chapter 6), and SQL injection (Chapter 7). As such, applying countermeasures to those potential vulnerabilities has the fortunate side effect of blocking authorization attacks as well.

Another best practice is to define clear, consistent access policies for your application. For example, design the user database to contain roles for the application's functions. Some roles are read, create, modify, delete, and access. A user 's session information should explicitly define which roles can be used. The role table looks like a matrix, with users defined in each row and their potential roles defined in each column.

Web Acl Best Practices

As we noted, the lowest common denominator of web app authorization is provided by ACLs, particularly file system ACLs (although we will cover ACLs on other objects like HTTP methods in our upcoming discussion). In this section, we'll describe best practices for web ACL configuration and then discuss how to configure ACLs on two popular web platforms, Apache and IIS.

Apache Authorization

The Apache web server uses two different directives to control user access to specific URLs. The "Directory" directive is used when access control is based on file paths. For example, the following set of directives limits access to the /admin URL. Only valid users who are also in the admin group can access this directory. Notice that the password and group files are not stored within the web document root.

 <Directory /var/www/htdocs/admin>   AuthType Digest   AuthName "Admin Interface"   AuthUserFile /etc/apache/passwd/users   AuthGroupFile /etc/apache/passwd/groups   Require group admin </Directory> 

You can also limit access to certain HTTP commands. For example, HTTP and WebDAV support several commands: GET, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK. The WebDAV commands provide a method for remote administration of a web site's content. Even if you allow WebDAV to certain directories, use the "Limit" directives to control those commands. For example, only permit GET and POST requests to user pages:

 <Directory /var/www/htdocs>   Options -MultiViews -Indexes -Includes   Limit GET POST     Order allow,deny     Allow from all   /Limit </Directory> 

Thus, users can only use the GET and POST commands when requesting pages in the /htdocs directory, the web root. The HEAD command is assumed with GET. Now, if you wish to enable the WebDAV options for a particular directory, you could set the following:

 <Directory /var/www/htdocs/articles/preview>   AuthType Digest   AuthName "Author Site"   AuthUserFile /etc/apache/passwd/users   AuthGroupFile /etc/apache/passwd/groups   Limit GET POST PUT CONNECT PROPFIND COPY LOCK UNLOCK     Require group author   /Limit </Directory> 

We haven't permitted every WebDAV option, but this should be enough for users in the author group who wish to access this portion of the web application.

The Location directive is used when access control is based on the URL. It does not call upon a specific file location:

 <Location /member-area>   AuthType Digest   AuthName "My Application"   AuthUserFile /etc/apache/passwd/users   AuthGroupFile /etc/apache/passwd/groups   Require valid-user </Location> 

Just about any of the directives that are permitted in <Directory> tags are valid for <Location> tags.

IIS Authorization

IIS provides similar security options for the types of access to a directory, although not to the same level of granularity. To configure access control for web directories and files, open the IIS Administration tool (iisadmin.msc), navigate to the computer and folder that you want to secure, and click Properties. On IIS5, this displays the interface shown in Figure 5-11, which illustrates a good set of default options to apply to directories that contain static HTML files. It is read-only and does not have execute access for scripts. This is especially important for directories to which users are permitted to upload files. It would be disastrous if an application permitted arbitrary files, including ASP files, to be uploaded and executed. The configuration options for IIS6 are almost identical.


Figure 5-11: Configuring IIS5 directory security (IIS6 is substantially the same .)

IP Address Authorization   Although we don't normally recommend it, IIS also permits IP addressbased access control. Configuration is accessible under the properties of a web site or directory, on the Directory Security tab. This might be useful in scenarios where only certain addresses, subnets, or DNS names are allowed access to an administration directory, for example. It's highly discouraged for Internet- facing applications, since 1) sequential requests are not guaranteed to come from the same IP address (think of the megaproxies like AOL), and 2) multiple users can come from the same IP address (think corporate networks).

Web Authorization/Session Token Security

As we've seen in this chapter, authorization/session security can be a complex topic. Here is a synopsis of authorization/session management techniques best practices:

  • Use SSL. Any traffic that contains sensitive information should be encrypted to prevent sniffing attacks.

  • Mark cookies using the "Secure" parameter of the Set-Cookie response header, per RFC 2109.

  • Don't roll your own authz. Off-the-shelf authorization features, such as those that come with web application platforms like ASP.NET and PHP that we will discuss shortly, are likely to have received more scrutiny in real-world environments than anything developed from scratch by even the largest web app development shops . Leave the security stuff to the professionals and keep focused on your core business. You'll suffer fewer vulnerabilities for it; trust us.

  • Don't include personally sensitive data in the token. Not only does this lead to session hijacking (since this data is often not really secretever tried finding someone's home address on Google?), but if it's disclosed, the user is out more than just some randomly generated session ID. The attacker may have stolen their government ID, secret password, or whatever other information was used to populate the token.

  • Regenerate session IDs upon privilege changes. Most web applications assign a session ID upon the first request for a URL, even for anonymous users. If the user logs in, then the application should create and assign a new session ID to the user. This not only represents that the user has authenticated, but it reduces the chances of eavesdropping attacks if the initial access to the application wasn't conducted over SSL. It also mitigates against session fixation attacks discussed earlier in the chapter, where an attacker goes to a site and gets a session ID, then e- mails it to the victim and allows them to log in using the ID that the attacker already knows .

  • Enforce session time limits to close down the window for replay attacks. Invalidate state information and session IDs after a certain period of inactivity (10 minutes, for example) or a set period of time (perhaps 30 minutes). In addition to relative per-session expiry, we recommend the application set global absolute limits on session lengths, to prevent attacks that attempt to fix session IDs far into the future. And always remember: the server should invalidate the ID or token information; it should not rely on the client to do so. This protects the application from session replay attacks.

  • Enforce concurrent login limits. Disallow users from having multiple, concurrent authenticated sessions to the application. This could prevent malicious users from hijacking or guessing valid session IDs.

To Be or to Impersonate

One of the most important questions when it comes to web app authorization is this: In what security (account) context will a given request execute? The answer to this question will almost always define what resources the request can access (a.k.a. authorization ). Here's some brief background to shed some light on this often misunderstood concept.

As we discussed in Chapter 1, web applications are client-server oriented. There are essentially two options for servers when it comes to honoring client requests:

  • Perform the request using the server's own identity (in the case of web applications, this is the web server/daemon); or

  • Perform the request by impersonating the client (or some other identity with similar privileges).

In software terms, impersonation means the server process spawns a thread and gives it the identity of the client (i.e., attaches the client's authorization token to the new thread). This thread can now access local server resources on the user's behalf just as in the simple authz model presented at the beginning of this chapter.

Note 

The impersonated thread may also be able to access resources remote to the first server; Microsoft terms this delegation and requires a special configuration and a higher level of privilege to perform this.

Web applications use both options just described, depending first upon the make and model of the web daemon and second upon whether the request is for a file system object or whether it's to launch a server-side executable (such as a CGI or ISAPI application). For example, Microsoft's IIS always impersonates access to file system objects (whether as a fixed account like IUSR_ machinename , or as the authenticated account specified by the client). For executables, it does not impersonate by default but can be configured to do so. Apache, on the other hand, does not impersonate requests for file system objects or executables, but rather executes everything within the security context of the web daemon process (although there are add-on modules that allow it to approximate impersonation of executables via setuid/setgid operations).

Caution 

Because web app authorization is mediated almost entirely by the web server daemon, be especially wary of vulnerabilities in web daemons that bypass the standard authorization mechanism, such as the IIS Unicode and Double Decode issues discovered in 2001.

In any case, it should be evident that the user account that runs the web server, servlet engine, database, or other components of the application should have the least possible privileges. We've included links to several articles in the "References and Further Reading" section at the end of this chapter that describe the details of which accounts are used in default scenarios on IIS and Apache, and how to configure them.

URL Authorization (AzMan)   In Windows Server 2003, Microsoft provided a role-based access control (RBAC) feature called Authorization Manager (or AzMan for short). AzMan was targeted at addressing the popularity of RBAC amongst large enterprises , permitting them to manage ACLs using a relatively simple set of enterprise-wide roles. IIS can be configured to leverage AzMan by enabling an ISAPI filter called URLauth.dll. This provides integration of IIS6-based applications into the enterprise-wide RBAC model. For more information about how to implement AzMan on IIS6, see the IIS documentation, as well as the "References and Further Reading" section at the end of this chapter.

ASP.NET Authorization   As with many Microsoft products, IIS is but one layer in a stack of technology offerings that can be composed into complex applications. For development efforts that decide to adopt Microsoft's IIS web server product, it's usually practical to also adopt their web development framework, Active Server pages (ASP), now called ASP.NET since its integration with Microsoft's broader .NET programming ecosystem.

ASP.NET provides some very compelling authorization options, the details of which are too voluminous to go into here. We strongly recommend checking out the article "How To: Use Windows Authentication in ASP.NET 2.0," linked in the "References and Further Reading" section at the end of this chapter, to understand the many flexible authorization options provided by ASP.NET.

One thing we would like to highlight for those that do implement ASP.NET: if you choose to specify authn/authz credentials in the <identity> elements of your Web.config files, you should encrypt them using either the Aspnet_regiis.exe tool (for ASP.NET version 2) or the Aspnet_setreg.exe tool (on ASP.NET version 1.1). In-depth descriptions of how to use these tools are available in the articles entitled "How To: Encrypt Configuration Sections in ASP.NET 2.0," linked in "References and Further Reading" at the end of this chapter.

Security Logs

Another access control countermeasure that often gets overlooked is security logging. The web application's platform should already be generating logs for the operating system and web server. Unfortunately, these logs can be grossly inadequate for identifying malicious activity or re-creating a suspect event. Many additional events affect the user's account and should be tracked, especially when dealing with financial applications:

  • Profile Changes   Record changes to significant personal information such as phone number, address, credit card information, and e-mail address.

  • Password Changes   Record any time the user's password is changed. Optionally, notify the user at their last known good e-mail address. (Yahoo! does this, for example.)

  • Modify Other User   Record any time an administrator changes someone else's profile or password information. This could also be triggered when other users, such as help desk employees , update another users' information. Record the account that performed the change and the account that was changed.

  • Add/Delete User   Record any time users are added to or removed from the system.

The application should log as much detail as possible. Of course, there must be a balance between the amount of information and type. For example, basic items are the source IP address, username or other identification tokens, date, and time of the event. An additional piece of information would be the session ID in order to identify users attempting impersonation attacks against the user tokens.

It might not be a good idea to log the actual values that were changed. Logs should already be treated with a high degree of security in order to maintain their integrity, but if the logs start to contain Social Security numbers, credit card numbers , and other personal information, then they could be at risk of compromise from an internal employee or a single point from which a malicious user can gain the database's most important information.



Hacking Exposed Web Applications
HACKING EXPOSED WEB APPLICATIONS, 3rd Edition
ISBN: 0071740643
EAN: 2147483647
Year: 2006
Pages: 127

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net