security and management issue in desiging a website

8/13/2019 Security and Management Issue in Desiging a Website

1/4

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

organied 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 authoriation decisions are based onthe 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 organied 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

"otential "roblem 'ue to /ad 'esign

Input alidation #ttacks performed by embedding malicious strings in %uery strings, form


2/4

fields, cookies, and !TT" headers. These include command execution,

cross-site scripting 01223, 245 in(ection, and buffer overflow attacks.

#uthentication Identity spoofing, password cracking, elevation of privileges, and

unauthoried access.

#uthoriation #ccess to confidential or restricted data, tampering, and execution of

unauthoried operations.

onfiguration

6anagement

7nauthoried access to administration interfaces, ability to update

configuration data, and unauthoried access to user accounts and account

profiles.

2ensitive 'ata onfidential information disclosure and data tampering.

2ession

6anagement

apture of session identifiers resulting in session hi(acking and identity

spoofing.

ryptography #ccess to confidential data or account credentials, or both.

"arameter

6anipulation

"ath traversal attacks, command execution, and bypass of access control

mechanisms among others, leading to information disclosure, elevation of

privileges, and denial of service.

*xception

6anagement

'enial of service and disclosure of sensitive system level details.

#uditing and

5ogging

Failure to spot the signs of intrusion, inability to prove a user&s actions,

and difficulties in problem diagnosis.

Re%ect &no'n Bad Inut'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.


3/4

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

security and management issue in desiging a website

Documents