SECURITY AND MANAGEMENT ISSUE IN DESIGING A WEBSITE

Web applications present a complex set of security issues for architects, designers, and developers. The most secure and hack-resilient Web applications are those that have been built from the ground up with security in mind. In addition to applying sound architectural and design practices, incorporate deployment considerations and corporate security policies during the early design phases. Failure to do so can result in applications that cannot be deployed on an existing infrastructure without compromising security. This chapter presents a set of secure architecture and design guidelines. They have been organi ed by common application vulnerability category. These are key areas for Web application security and they are the areas where mistakes are most often made..

Architecture and Design Issues for Web A

!ications

Web applications present designers and developers with many challenges. The stateless nature of !TT" means that tracking per-user session state becomes the responsibility of the application. #s a precursor to this, the application must be able to identify the user by using some form of authentication. $iven that all subse%uent authori ation decisions are based on the user&s identity, it is essential that the authentication process is secure and that the session handling mechanism used to track authenticated users is e%ually well protected. 'esigning secure authentication and session management mechanisms are (ust a couple of the issues facing Web application designers and developers. )ther challenges occur because input and output data passes over public networks. "reventing parameter manipulation and the disclosure of sensitive data are other top issues.

Web application design issues The design guidelines in this chapter are organi ed by application vulnerability category. *xperience shows that poor design in these areas, in particular, leads to security vulnerabilities. Table +., lists the vulnerability categories, and for each one highlights the potential problems that can occur due to bad design. Web A !ication "u!nerabi!ities and #otentia! #rob!e$ Due to Bad Design -ulnerability .ategory Input -alidation "otential "roblem 'ue to /ad 'esign #ttacks performed by embedding malicious strings in %uery strings, form

fields, cookies, and !TT" headers. These include command execution, cross-site scripting 01223, 245 in(ection, and buffer overflow attacks. #uthentication #uthori ation .onfiguration 6anagement 2ensitive 'ata 2ession 6anagement .ryptography "arameter 6anipulation *xception 6anagement #uditing 5ogging Identity spoofing, password cracking, elevation of privileges, and unauthori ed access. #ccess to confidential or restricted data, tampering, and execution of unauthori ed operations. 7nauthori ed access to administration interfaces, ability to update configuration data, and unauthori ed access to user accounts and account profiles. .onfidential information disclosure and data tampering. .apture of session identifiers resulting in session hi(acking and identity spoofing. #ccess to confidential data or account credentials, or both. "ath traversal attacks, command execution, and bypass of access control mechanisms among others, leading to information disclosure, elevation of privileges, and denial of service. 'enial of service and disclosure of sensitive system level details. and Failure to spot the signs of intrusion, inability to prove a user&s actions, and difficulties in problem diagnosis.

Re%ect &no'n Bad In ut

'eny 8bad8 data9 although do not rely completely on this approach. This approach is generally less effective than using the 8allow8 approach described earlier and it is best used in combination. To deny bad data assumes your application knows all the variations of malicious input. :emember that there are multiple ways to represent characters. This is another reason why 8allow8 is the preferred approach. While useful for applications that are already deployed and when you cannot afford to make significant changes, the 8deny8 approach is not as robust as the 8allow8 approach because bad data, such as patterns that can be used to identify common attacks, do not remain constant. -alid data remains constant while the range of bad data may change over time.

Authentication
#uthentication is the process of determining caller identity. There are three aspects to consider; Identify where authentication is re%uired in your application. It is generally re%uired whenever a trust boundary is crossed. Trust boundaries usually include assemblies, processes, and hosts. -alidate who the caller is. 7sers typically authenticate themselves with user names and passwords. Identify the user on subse%uent re%uests. This re%uires some form of authentication token.

6any Web applications use a password mechanism to authenticate users, where the user supplies a user name and password in an !T65 form. The issues and %uestions to consider here include; Are user na$es and ass'ords sent in !ainte(t o)er an insecure channe!* If so, an attacker can eavesdrop with network monitoring software to capture the credentials. The countermeasure here is to secure the communication channel by using 2ecure 2ocket 5ayer 02253. +o' are the credentia!s stored* If you are storing user names and passwords in plaintext, either in files or in a database, you are inviting trouble. What if your application directory is improperly configured and an attacker browses to the file and downloads its contents or adds a new privileged logon account< What if a disgruntled administrator takes your database of user names and passwords< +o' are the credentia!s )erified* There is no need to store user passwords if the sole purpose is to verify that the user knows the password value. Instead, you can store a verifier in the form of a hash value and re-compute the hash using the usersupplied value during the logon process. To mitigate the threat of dictionary attacks against the credential store, use strong passwords and combine a randomly generated salt value with the password hash. +o' is the authenticated user identified after the initia! !ogon* 2ome form of authentication ticket, for example an authentication cookie, is re%uired. !ow is the cookie secured< If it is sent across an insecure channel, an attacker can capture the cookie and use it to access the application. # stolen authentication cookie is a stolen logon.

Authori,ation
#uthori ation determines what the authenticated identity can do and the resources that can be accessed. Improper or weak authori ation leads to information disclosure and data tampering. 'efense in depth is the key security principle to apply to your application&s authori ation strategy. The following practices improve your Web application&s authori ation; Use $u!ti !e gate-ee ers. Restrict user access to s.ste$/!e)e! resources. Consider authori,ation granu!arit.. .