web app security standard

8/11/2019 Web App Security Standard

1/24

This document is provided without warranty, always vet out what works best for youand your organization.

Web Application Security Architecture Standard

Scope

This standard applies to all corporate equipment and data, including corporatecustomer data, whether located at a corporate facility or a third party facility, andwhether handled by corporate employees, or corporate contractors, vendors, thirdparty service providers, or their staff or agents. This standard also applies to allwholly owned and partially owned subsidiaries.

The guidance in this standard shall be considered the minimum acceptablerequirements for the use of Web Application Security Architecture. This standardsets forth epectations across the entire organization. Additional guidance andcontrol measures may apply to certain areas of corporate. This standard shall notbe construed to limit application of more stringent requirements where !ustified bybusiness needs or assessed risks.

Web Application Security Architecture Standard"orporate#s business functions rely upon the integrity, confidentiality, andavailability of its computer systems and the information assets stored within them.$esponsibilities and procedures for the management, operation and security of allinformation processing facilities must be established. This standard supports thestated ob!ectives.

$oles % $esponsibilities

The &evelopment Security 'ead is a member of the development team that will bethe main point of contact within the development team for security relatedquestions throughout the software development lifecycle.

The Security Advisor is not a member of the development team and guides theteam in following the secure coding practice. The Security Advisor will perform thefinal security review approval.

The (ro!ect )anager communicates security information to all teams and ensuressecurity pushes are scheduled and performed. They keep *A and development ofchanges in security practice.

*uality Assurance tracks software defects and security vulnerabilities separatelyand communicates them to development.

The +nformation Security &epartment will assist nd -sers and +T "ustodians inassessing, defining, implementing, managing and monitoring appropriate controlsand security measures.


2/24

The +nformation Security &epartment will audit and review the adequacy of controlsand security measures in place to measure and enforce conformance to thisstandard.

Web Application Security (rinciplesThe following software security architecture principles should be considered whendesigning applications at corporate.

ail Safe / 0our application must always fail safe. That is to say if itencounters a situation and it can no longer proceed, it must deny access tothe resource. or eample, if a firewall cannot validate the action that is beingrequested by the requester, it should re!ect the operation1 this is known asfail close or fail safe.

Security through 2bscurity does not Work 3 2bscurity should not be used asthe only or primary security mechanism.

Simplicity / "ompleity increases the potential risk of problems. Applicationarchitecture and implementations should be as simple as is practical. This alsomakes it easy to do the right thing.

nd to end security 3 Where data requires protection during transportation, itshould be enforced from the sender to the recipient 4end to end5.

"ompartmentalize / Applications should compartmentalize user access."ompartmentalization provides user access to data and functions that theyrequire and restricts them from accessing data or functions they do not need.

&efense in &epth / Applications should use multiple layers of security. Thisensures that if one security mechanism is vulnerable to an attack, anadditional layer will still enforce an adequate security policy. (assword files foreample, should be restricted by access control lists and encryption. Similarlyeven if data is validated, the use of stored procedures or prepared S*'statements is strongly recommended since it adds an additional layer ofdefense.

'east (rivilege 3 Applications should run with the minimum amount of systemprivileges that they need to function. Where elevated privileges are required

they should be granted for the minimum period of time they are required. Asimilar principle is the 6need to know7 principle. nsure that only theminimum number of people have administrative level access to productionweb, database and application servers.


3/24

Trust but 8erify 3 Applications need to trust other applications or ob!ects onthe same host or on the network however, they must always verify the sourcethey are trusting. The same also applies to users and their actions. orinstance, before performing any administrative action, it is important to checkthat the requesting user is indeed an administrator authorized to request suchan action.

Think Strategically 3 There are no security silver bullets. Security requires constantmonitoring and improvement and is not somebody else#s responsibility. (ay specialattention to architecting the right solution so that it maybe reused frequently. Theuse of software design patterns and frameworks like 9A8A Struts are thereforestrongly encouraged.

Security ArchitectureA typical architecture for web applications could be considered as having threema!or layers:

(resentation 'ayer 3 presents data to the client via a web server.;usiness 'ogic 'ayer 3 performs business logic.nterprise +nformation Store 4+S5 3 storage of persistent data typically in adatabase server.

The presentation layer normally resides in a semi/trusted environment suchas a firewall &)


4/24

Access "ontrolso nsure that the A"'s and rulesets are correctly defined as required by the

application and business.

;lock all unnecessary ports and services and lock down administrative interfaces tobe inaccessible via the +nternet and only accessible from specific hosts.

o Administrative interfaces A'' require $A&+-S or TA"A"s authentication.

o =etwork A"'s may be used if needed.

o -se the &efault &eny security principle.

Auditing and 'oggingnsure that logging is enabled for all dropped>denied traffic and that the logs arestored centrally in a secured location, potentially on a separate 8'A=.Setup a workflow to ensure that logs are monitored regularly to detect attackpatterns.

o nsure that all logging devices operate on a synchronized clock.

o +ntrusion &etection> (revention

o Setup +&S sensors both in the &)< and in the trusted network to detect

attacks.

o Setup remediation workflows that include automatic event notification.

actory &efaults)ake sure that all factory default user names and passwords as well as othersecurity settings like +&s are changed to new ones with sufficient compleity.

Securing the Web Server+n dealing with the web server it is imperative to apply many of the same principlesdescribed above for network devices. The following table lists the issues that mustbe considered:

o (atches and Security -pdateso nsure that the operating system has the latest updates, patches and service

packs.o Similarly the web server and any programming frameworks must be kept up

to date.

Access "ontrols;lock all unnecessary ports and services and allow only port ?@ 4TT(5 and ifrequired BBC 4SS'5 to be open.


5/24

'ock down administrative interfaces to be inaccessible via the +nternet and onlyaccessible from specific hosts.

nsure there are no world writable files and that all files are permissioned accordingto the business logic.

"onfiguration&o not run multiple services such as T( or ==T( of the same machine.&isable Web&av if running and unused.

nsure that the accounts being used by the daemon or service adhere to theprinciple of least privilege.

&elete any unused accounts such as guest.$ename the default super user account and use a strong password.

&isable unsecured remote logons such as Telnet and enable SS or other secureremote logon protocols only if needed.

All sample websites, applications, backups or development tools must be removedfrom the production web servers.

The web root should be on a different file system from the operating system filesand directory traversal or listing must be disabled.

-nused script etensions must be disabled and mapped to the default TT( B@B

page.

2nly the necessary TT( commands should be enabled. This is typically A&, DTand (2ST. T$A", 2(T+2=S and other unused commands must be disabled.

Auditing and 'oggingAll login failures must be logged along with the source of the failed login.

$esource access failures must be logged.'ogs should be collected or written to a remote hardened logging server.'og files must be regularly backed up and archived.

Securing the Application Server(atches and Security -pdatesnsure that the operating system has the latest updates, patches and servicepacks.Similarly the application server and programming framework must be kept up todate.Transport Security-se SS' or +(Sec to protect communication to and from the application server.


6/24

-se encrypted $(", E)' digital signatures and WS/Security for web services.-se a segmented network which can isolate eavesdropping to compromisedsegments.

Access "ontrolnsure there are no world writable files and that all files are permissioned accordingto the business logic.

nsure that the accounts being used by the daemon or service adhere to theprinciple of least privilege.

&elete any unused accounts such as guest.

&isable unsecured remote logons such as Telnet and enable SS or other secureremote logon protocols only if needed.

nsure only the necessary ports are accessible outside the firewall protecting the

application server.

+f possible use +(Sec policies to restrict host connectivity.

"onfiguration

&o not run multiple services such as T( or ==T( of the same machine.

All sample websites, applications, backups or development tools must be removedfrom the production servers.

o

"onfigure session management options via the appropriate configuration tools> E)' files e.g. weblogic.ml on ;A Web'ogic so that session +&s andcookies are generated with sufficient randomness and relatively shortlifetimes.

o Similarly configure session timeouts as per the guidelines provided later in

this document.o Auditing and 'ogging

o nable detailed logging options that are supported by the application server.

o All login failures must be logged along with the source of the failed login.

o $esource access failures must be logged.

o

'ogs could be written to a remote hardened logging server.o 'og files must be regularly backed up and archived.

o Securing the &atabase Server

The following table lists the requirements for a secure database server:

(atches and Security -pdatesnsure that the operating system has the latest updates, patches and servicepacks.


7/24

o Similarly the database server and any database connectivity components like

2&;" and 9&;" drivers are patched and up to date.

Access "ontrolso ;lock all unnecessary ports and services and allow only the specific ports

needed by the database server being used.o

&o not run multiple services such as T( or ==T( of the same machine.o nsure there are no world writable files and that all files are permissioned

according to the business logic.o &isable etended stored procedures that allow command eecution if not

needed by the application.o "onfiguration

o nsure that the accounts being used by the database daemon or service

adhere to the principle of least privilege.o &elete any unused accounts such as guest.

o $ename the default super user account and use a strong password.

o &isable unsecured remote logons such as Telnet and enable SS or othersecure remote logon protocols only if needed.

o All sample databases and tables must be removed from the production web

servers.o &atabase files maybe stored on an encrypted file system if supported by the

operating system and database server.o Auditing and 'ogging

o All login failures must be logged along with the source of the failed login.

o nable database server logging.

o $esource access failures must be logged.

o 'ogs could be written to a remote hardened logging server.o 'og files must be regularly backed up and archived.

actory &efaultso "hange the default database administrator password.

o "hange the default port used by the database server for additional security.

o nsure that the database server roles do not contain any unnecessary users

such as the guest or anonymous account and disable unused roles.

AuthenticationAuthentication for a web application in practice takes the following three forms:

o -ser Authentication

o (assword ;ased

o TT( ;asic > "lear Tet

o TT( &igest

o Shared Secret 4Ferberos > =T') vG5


8/24

o 2ne Time (assword 4tokens > $SA token or S>Fey5

o (ersonal &igital "ertificates

o ;iometrics

o Session Tokens

o "ookies

o AS(>9A8A Session +&s

o ntity > "omponent Authenticationo "ode Signing "ertificates

o Strong =ames

o Authenticode

o 9A$ Signing

o Server Authentication

o +(S"

o (F+

o E.H@I "ertificates

All credentials in any form must be transmitted over an encrypted tunnel 4SS'>T'Susing a minimum JG? ;it encryption5. This implies that the TT( > "lear TetAuthentication scheme is not permitted for use. TT( &igest Authentication is alsonot permitted since it does not allow for effective user management.

specially for web applications, it is important to clearly separate public andrestricted areas of the website. or all public data, the authentication mechanismsand SS' is optional. All private data must require authentication over an encryptedtunnel at a minimum using some form of shared secret such as a password.or all confidential data and sensitive data a minimum of two factor authentication

is required, for eample using client certificates and tokens.

+f password authentication is used, then besides the SS', a one way hash functionlike SA/G must be applied to the password using a salt before transmission andstorage in the database. Thus, no one but the user can know what his>her passwordis. ven if someone has access to the database, the best they can hope to view isthe salted password hash. As a best practice when using passwords the use of achallenge response type protocol is highly recommended to prevent transmittingthe password or it#s hash over the wire.

o 9A8A developers as a best practice should leverage the 9A8A Authentication

and Authorization Service present in the 9A8A S&F. This service provides anA(+ for performing user based authentication and authorization.

o All content that is available prior to authentication should be etensively

eamined for vulnerabilities. Attackers will be able to scour this for facts touse later.

o 8erify authentication mechanisms check for boundary conditions such as null

and 67 empty strings within user input fields.

"heck for common user account names and passwords


9/24

nsure that error pages for incorrect user names, incorrect passwords, and multiplelogon failures result in identical error pages. This prevents revealing details aboutwhether or not the userid or password was correct.

Analyze the lockout procedures to determine &enial of Service attacks. Acompromise will need to be made between lockout policy and &oS possibilities.

AuthorizationThree fundamental authorization or access control models are used in practice.&iscretionary Access "ontrol is operator driven i.e. the owner of the resourcedetermines the permissions on the resource. This is most commonly seen incommercial operating systems through permissions on files, sockets and other suchsecurable ob!ects. )andatory Access "ontrol on the other hand uses a classificationscheme common in government and defense installations to ensure the integrityand confidentiality of primarily data resources. A third hybrid model is $ole ;asedAccess "ontrol. The ma!or advantage of this model is that it allows the application

to leverage the underlying operating system#s security subsystem while adapting itto be application specific. (rogrammatically, authorization usually occurs based on asecurity token issued to the user when he>she logs in to the application. orinstance, cookies or session +&s are often used as such security tokens in webapplications. ;ecause of the fleibility it offers, the use of role based access controlis strongly encouraged across all applications that build their own authorizationschemes. +f an etensive and specific authorization model is not required, then theunderlying operating system#s access control infrastructure maybe leveraged.

$ole ;ased Access "ontrol

$ole based access control 4$;A"5 should be the preferred authorization fordevelopers building applications. Along with the advantages mentioned above,$;A" also has the advantage that it can very easily be centralized so as to provideone authorization entry point into the system. $;A" has language level support in9A8A>9G using the deploytool as well as in .=T and "2)K through theSystem.Security.(ermissions namespace and the 2b!ect"ontet ob!ect respectively.Application designers and developers looking to implement authorization should usethe following step/wise approach:

+dentify the resources that need to be protected. amples of such resourcesinclude customer data such as social security numbers and credit card information,

application configuration data such as database connection strings, cryptographickeys and passwords as well as the application code, eecutables and processesthemselves.

The net step is to identify the actions>operations that can and>or cannot beperformed over the resources. Typical operations include reading, writing, creatinga new instance and modifying or deleting an eisting instance.


10/24

+dentify the roles in the application. These typically can be obtained from the use/case scenarios for the application where they are often represented as the actors orsub!ects. +t is important at this stage to identify hierarchies as well. )ostapplications requiring authentication would have at least three roles: anunauthenticated user, an authenticated user and a super user or administrator.Typically, the capabilities of each of these roles are contained within the higher levelrole. This implies that an authenticated user for instance can do everything aunauthenticated user can do plus more.

$oles are typically mapped to operating system groups. )ost commercial operatingsystems support the concept of a group and by leveraging this, the applicationdeveloper can ensure that the operating system reference monitor will enforce anyaccess control that has been defined. Similarly, it follows that individual operatingsystem user accounts can be created to represent the application specific users.These users can then be placed in groups based on their assigned roles. or webbased applications dealing with large number of accounts, it is recommended to notuse the underlying operating system accounts since this can cause a large

overhead. +n such cases, applications may create their own users and roles whichmust be stored in the database. While the steps described here remain identical,the application is now responsible for acting as the reference monitor and enforcingaccess control based on the requesting role.

The final step in this process is to identify the authorization constraints. This stepsaims to bring the resources, the actions that maybe performed on those resourcesand the roles together to define which roles can perform what operations. orinstance, one might have a constraint that an unauthenticated user may only viewthe home page and the contact information page.

An authenticated user could view all the pages so long as they only containinformation specific to him>her. inally, only an administrator is allowed access tothe user management page for creating>deleting users and resetting passwords.Authorization decisions must be made as close to the resource being protected aspossible. or eample, if the data in a database table is being protected, then thedatabase or data layer is best suited to make the authorization decision. This alsoenhances the ability of the application to define fine/grained privileges.

As a best practice, using Secure -)' to document the above steps is highlyrecommended. ;y the usage of familiar -)' notation diagrams, it is possible toidentify flaws such as backdoors and multiple entry paths. &iagramming tools like

$ational $ose have the advantage that they can be far more eplicit than verbosetet thus uncovering any underlying assumptions.

Access "ontrolAny authorization scheme is only as secure as it is implemented. +t is thereforecritical that developers do not epect the operating system, the system deployer oradministrator to define access control. &efining file system A"'s is an ecellenteample of this and must be set by the application itself potentially during theinstallation process. )ost large database vendors support at least table level access


11/24

control. +f needed third party database shims maybe used to etend this further tocolumn level access. +n keeping with the role/based approach discussed above, theresources should have A"'s defined using the operating system group and useraccounts that the application roles map into.

Whenever, a request is made from outside the trust boundary of a component thecomponent must authorize the request. or instance, if a database modification isrequested by an application that resides outside the trust boundary for thedatabase, then the database must request authorization irrespective of whether theapplication has performed authorization or not.

+mpersonationThe principle of least privilege must be adhered to by all application developers andarchitects. A common way of implementing this principle is through the use ofimpersonation. 2n -=+E systems for instance this is commonly done using setuidand>or setgid. Thus, only if absolutely needed, should an application run as anelevated user. ven when the need for impersonation is unavoidable, developers

should ensure that the privilege is used for an etremely short and finite durationand for a specific resource. +f elevated privileges are needed in multiple parts of theapplication then privileges must be raised and dropped separately rather thanraising them for an etended period of time. The impact of eceptions whenprivileges are raised must also be kept in mind. Typically this is best handled usingthe finally clause to lower privileges since it will be eecuted irrespective of whetheran eception is raised or not.

&evelopers must avoid the temptation of using elevated privileges because it makes

development easier. There are easy ways to avoid the need for elevated privileges,for instance the >tmp directory is most often world writable, hence if temporary filesneed to be created this is an ecellent place to do so, rather than in the applicationdirectory itself which typically should be only root>owner writable. When privilegesare elevated programmatically a few issues must be kept in mind. All function andsystem calls made from that point on till privileges are reduced will operate at theenhanced privilege1 hence the function callees must be aware of this and take itinto account. Another common issue to watch out for is what is described as theTime of "heck 3 Time of -se 4T2"T2-5 problem. &evelopers must ensure thatbefore an authorization decision is made the application must be able to satisfyitself that the security token it is referencing is the one that is most current, valid

and indeed belongs to the user making the request. +f there is a significant time lagbetween check for access and performing an operation then a malicious attackermay have the opportunity to change the operation to be performed. A commonmanifestation of this is when application uses symbolic links. An attacker canattempt to change the location to which the link points to after the access check hasbeen performed. Similarly, if the access check is performed when running inelevated privileges and is not re/done when privileges are lowered, access maybefalsely granted to a resource.


12/24

Session )anagementApplication developers especially those creating web applications must pay specialattention to session management. This includes aspects such as the security of thesecurity tokens and session inactivity timeouts.

&esigners and developers should leverage the underlying frameworks 4whether9G or AS(>AS(.=T5 session management capabilities as far as possible. Thesecapabilities typically manifest themselves via a session +&. +nfrastructure suppliedsession +&s have the advantage of being sufficiently random so that an attackercannot attempt a guessing or brute force attack. The application must never rely on!ust the username submitted with a request when determining the session to whichthe request belongs to. Session +&s issued by the application frameworks alsotypically have a relatively short lifetime and thus can prevent the 6permanentlylogged in7 effect.

An application that seeks to create its own session management capabilities musthave eplicit written prior approval from the +nformation Security &irector. urther,

the following directives must be followed:

"ookies are the preferred mechanism. These are also commonly used in associationwith session +&s. When using cookies, developers must clearly define the cookieepiration date and time as well as ensure that the cookie is not persistent. Afterthirty minutes of inactivity, the user must be forced to re/login.

"ookies must be marked secure for SS' connections to ensure they do not initiateconnections over clear tet connection.-sage of secure cookies is required whenever the application uses the cookies for

security purposes. Special care must be taken when the application switchesbetween secure 4SS' protected5 and insecure modes, so as to ensure that thecookies are not eposed when traversing the wire in insecure mode. Anothercommon mistake that developers often make is to not issue a fresh session +&when the application switches from an insecure mode 4used typically before a userlogs in to the application5 to a secure mode 4after log in5. Thus an attacker who hasobtained a cookie by sniffing traffic can wait for the legitimate user to log in andthen use that cookie to impersonate him>her.

"ookies must never contain sensitive information such as passwords.All application defined session identifiers or cookies must have at least JG? bits of

entropy. This typically equates to JL or more AS"++ characters. Alphanumericcharacters must be used if cookies are used for session management or othersecurity purposes.

When the user is logged out, the session must be invalidated both on the serverside and the client side. This is typically done by deleting the session entry from theserver data store as well as by clearing the cookie in the client application orbrowser.


13/24

The user should =2T be sending session data back to the server. Security sensitivesession data should be stored only on the server.

Avoid using the DT method to transport session +&. The session +& will be loggedin the referrer log or easily manipulated when passed in the -$'.

Analyze every session variable for misuse. ocus on invoking pages and out ofsequence as in the following eample:

Mdisplay.phpif 4NO(2STP6action7QRR7display75

displayOaccount4NOSSS+2=P6account7Q51else if 4NO(2STP6action7QRR7select75 if 4isOmyOaccount4NO(2STP6account#Q55

%OSSS+2=P6account7QRNO(2STP6account7Q1displayOmenu451

else

displayOerror451

Mtransfer.phpif 4NO(2STP6action7QRR7startOtransfer75

NOSSS+2=P6account7QRNO(2STP6destinationOaccount7Q1NOSSS+2=P6accountG7QRNO(2STP6sourceOaccount7Q1NOSSS+2=P6amount7QRNO(2STP6amount7Q1displayOconfirmOpage451

else if 4NO(2STP6action7QRR7confirmOtransfer75

Nsrc R NOSSS+2=P6account7Q1Ndst R NOSSS+2=P6accountG7Q1Namount R NOSSS+2=P6amount7Q1if 4validOtransfer4Nsrc, Ndst, Namount55

&oOtransfer4Nsrc, N&st, Namount51else

&isplayOerrorOpage451

The session variable NOSSS+2=P6account7Q is used in both display.php andtransfer.php, but for different purposes and security controls. An attacker can use


14/24

transfer.php to set the value of SSS+2=P6account7Q and then go to display.php anddisplay the contents of the account.

ven though session variables are only set on the server, careful analyses of sessionvariable usage should be performed in all cases.

&ata should not be left in session variables after an error condition. rror logicshould be performed first. it conditions should not set session or persistent datastores unless the error conditions are passed.

&o not accept session keys that are not generated by the application server.

(rotect the session validation mechanism from brute force attacks

Analyze the load balance structure for security vulnerabilities

Session token transmission must be protected. The session token can be stored in

either cookies, hidden form fields, or -$' parameters. Will this data be stored onweb proies, browser histories, sniffers or web behavior monitorsU

-ser )anagementThe following user management standards must be implemented across allapplications.

-ser =ames-ser names must be unique and must never contain personally identifiableinformation such as the social security number of a user. -ser names must be aminimum of L characters long.

(asswords"ompleity / All user passwords must be a minimum of ? characters long.Administrator passwords must be a minimum of JG characters long. (asswordsmust be alpha numeric and must be case sensitive.

Storage / All passwords must be stored in an encrypted form. "orporate approves

the use of the SA/G algorithms to provide one way hashing. All passwords must behashed with a salt value of no less than ? AS"++ characters for a user.

piry / A user account accessing confidential or secret information must requirepasswords to be changed after I@ days. An administrative account password mustbe epired after C@ days.

(assword $eset )echanisms


15/24

or password resets, the approved method is the answer to a secret question.2nline password reset systems can be implemented using this method. A secretquestion and secret answer should be captured at registration or during asubsequent authenticated session. These questions should be free form, i.e., theapplication should allow the user to create his>her own question and thecorresponding answer rather than selecting from a set of predetermined questions.

Secret answers must be stored in an encrypted form. The cryptography sectionbelow lists the algorithms that maybe used for this purpose.

As passwords cannot be recovered even by the system, when the user provides thecorrect answer to the question, the system must generate a new random passwordand send it to the user 6out of band7 i.e. not be rendered to the screen. A source ofrandomness such as >dev>random on -=+E systems may be used for this purpose.

"orporate approves the use of sending the new password to the user at a pre/registered email address. The password must be set to change the first time the

new user logs on with the changed password. (assword resets must be logged.Account 'ockout+f an attacker is able to guess passwords without the account becoming disabled,eventually he>she will be able to guess at least one password using brute forcetechniques.

A user must be locked out of the system after H bad attempts and the account canbe re/enabled after administrative intervention or at least C@ minute delay. All badpassword attempts must be logged and the user must be sent an email at pre/

registered email address informing him > her of the lockout.This guidance maybe be modified depending on the application#s purpose and data.ighly sensitive banking information may require a phone call to re/enacle, whilegeneral authentication access to a marketing site may only require delays afterinvalid attempt sequences.

"ryptographyStrong cryptography must be used both for transport security as well as forsecuring storage. "ryptogaphy must be used to achieve confidentiality, integrity,authentication and > or non/repudiation. or instance, passwords stored indatabases must be hashed with a salt using a one/way function like SA/G. or

transport security, SS' must be used. The servers must support at least mediumencryption cipher suites as described in the 2penSS' documentation. Anonymous&iffie/ellman may never be used as the key echange method. This algorithminvolves no authentication and hence is susceptible to a man/in/the/middle attack.Server certificates must be relatively short lived bearing in mind that thecapabilities to brute force keys increase dramatically each year. pired certificatesor revoked certificates must be quickly replaced so as to avoid any misuse. (rivatekeys used during certificate creation must be stored securely using mechanismsdescribed below in the Fey Storage section. As a best practice, whenever possible


16/24

SS' based applications should insist on mutual authentication of the client andserver using E.H@I certificates.

Approved Algorithms&evelopers may not and should not attempt to devise their own cryptographicprimitives. -se of any form of reversible or non/deterministic encryption such assimple rotation or substitution ciphers is prohibited. The following table lists thealgorithms and minimum key lengths that are permitted for use within applications:

Algorithm Feychange)ethod

)inimumFey 'ength

Fey'ifetime

$ecommended -sageScenarios

AS $SA GHLLmonths3 J year

;ulk encryption4files, databases5

$SA

(ublic Fey

+nfrastructure G@B?

J/G

years

Fey echange,

secure messaging.

SA/G =>A =>A =>A+ntegrity, saltedpassword hashing

&evelopers must note that encryption on its own does not guarantee integrity. -seof SA/G hashes is necessary to meet integrity requirements.

Fey Deneration and )anagementAs far as possible keys must be generated and stored offline in secure storage. Feysmaybe generated using the keytool utility in the 9A8A S&F. 2penSS' providessimilar functionality. The 9A8A framework supports keystores that are pass/phraseprotected. +f session keys have to be created dynamically the 9A8A keystore ob!ectrepresents an in/memory collection of keys and certificates. 2n )icrosoft platformsthe )icrosoft "ryptography A(+ 4"ryptoA(+5 or the &ata (rotection A(+ 4&(A(+5must be used to store and create keys.

&ata 8alidation

The lack of data validation is primarily responsible for a large number of attacksagainst software. These include buffer overflows, S*' in!ection and cross sitescripting. +n order to prevent such attacks developers must validate all data as itflows across the trust boundaries of the application. While this can have a minorperformance hit it is important to note that a marginally slower application is farmore useful than a hacked application.

Trust ;oundaries


17/24

As application developers the first step is to define the trust boundaries for theapplication. Trust must be essentially defined by what you as an individualdeveloper or group have control over. "ommon eamples of this could include theweb browser and the T)' content versus the web server or your applicationversus a third party component or automated data feed. A methodical approach ofidentifying all inputs and outputs without making assumptions about what othercomponents will be doing must be followed in determining the trust boundaries.2ne must also be very careful about partial trust. +n most cases it is best to nottrust at all in such cases rather trusting sometimes. Trust is also impacted byattributes such as file system A"'s. or instance, if configuration information is readfrom a while that is world writable then its contents can never be trusted.

"lient Side 8alidationAs developers of client server software it is important to never trust the client, evenif you wrote it and it is a thin client. +t is trivial to use applications such as webproies and code dis/assemblers to reverse engineer clients or negate the effects ofany client side validation. ence, developers must perform validation on the server

side. As a best practice and for performance reasons, client side validation maybeperformed to prevent unnecessary server round/trips if legitimate users makeinnocent mistakes while entering input. Sensitive information must never be placedon the client side. or instance, developers must not place product attributes suchas the price in a hidden T)' form field and then trust that price to be correct.

&ata Sanitization+f developing in a scripting language, even though the language permits latebinding and weakly typed code, this must be avoided. Additionally, whereverpolymorphism is in use, it is important to check the type of arguments passed in

before operating on them. This can be done using reflection in both 9A8A and .=Tor by using the "KK casting operators.specially when developing in languages such as " and "KK, developers areresponsible for bounds checking so that no buffer is filled with more data than it cansafely occupy. -se of the standard template library 4ST'5 is recommended as a bestpractice for dealing with such problems. &ata sanitization must also be performedbefore validation is performed since attackers might attempt to bypass thevalidation using TT( or -=+"2& encoding.

String 8alidation and (reventing S*' +n!ectionString validation must be performed using regular epressions. ;oth the .=T and

9A8A programming frameworks provide support for regular epressions. The!ava.util.rege.V package in the 9A8A S&F is an ecellent eample of this.

specially with web applications, developers must be filter common cross sitescripting,

S*' in!ection and E(AT in!ection meta/characters such as those shown in thefollowing table:


18/24

PJQ 4pipe sign5PGQ % 4ampersand sign5PCQ 1 4semicolon sign5PBQ N 4dollar sign5PHQ X 4percent sign5PLQ Y 4at sign5PZQ [ 4single apostrophe5P?Q \ 4quotation mark5PIQ ][ 4backslash/escaped apostrophe5PJ@Q ]\ 4backslash/escaped quotation mark5PJJQ ^ 4left triangular parenthesis5PJGQ _ 4right triangular parenthesis5PJCQ 4 4left parenthesis5PJBQ 5 4right parenthesis5PJHQ K 4plus sign5PJLQ "$ 4"arriage return, AS"++ @@d5PJZQ ' 4'ine feed, AS"++ @@a5

PJ?Q , 4comma sign5PJIQ ] 4backslash5PG@Q 3 4dash or minus sign5PGJQ P 4left bracket5PGGQ Q 4right bracket5


19/24

'&A( +n!ection'&A( in!ection like S*' in!ection can also occur where queries are reading ormodifying directory services. -sing positive validation by allowing alphanumericcharacters 4A..


20/24

[_[ \%gt1\[\[ \%quot1\[][[ \%MCI1\[X[ \%MCZ1\[1[ \%MHI1\[4[ \%MB@1\[5[ \%MBJ1\[%[ \%amp1\[K[ \%MBC1\

+t is important to consider how data is intended to be rendered in the clientsbrowser in order to determine what character encoding should be performed. Thereare seven categories of T)' output that require different encoding strategies, aseach is interpreted differently. To ensure that the correct encoding is beingemployed use libraries from trusted sources to apply the encoding.

These libraries as a whole provide encoding for several common T)' output types

3 plain T)', T)' attribute, -$', 9avaScript, 8;Script, E)', and E)' attribute.amples using these encoding libraries:

(lain T)':^html_ ^body_ Thank for typing:^XR$eform.tmlncode4$equest.*ueryStringP\userOinput\Q5X_ ^>body_^>html_

$eform.tmlncode46^script_ alert4`test#5 ^>script751

T)' attribute:

^html_ ^body_k ^img srcR[image.!pg[

altR[^XR$eform.tmlAttributencode4$equest.*ueryStringP\alt\Q5X_[ >_ ^>body_

^>html_

"anonicalization"anonicalization involves converting a directory or file path into its simplest andabsolute form. or eample:

":]&ocumentsandSettings]9ohnOSmith]&esktop]&oes=otist]&=]..]..]special.docWhen canonicalized refers to:":]&ocumentsandSettings]9ohnOSmith]&esktop]special.doc


21/24

+t#s important to first decode or epand all user input before canonicalizingpathnames. -sers can use many different encodings of ..>..> to trick applicationsinto providing access unintended files. This is eploited by attackers since the samesymbol can have multiple representations. or instance, %lt1 %MCc1, %ML@1 all referto the ^ symbol. Similarly -$' and -=+"2& encoding result in multiplerepresentations.

+nternationalization&evelopers are required to use the -=+"2& -T/? encoding scheme as thecharacter set for their applications. This is intended to prevent problems arising dueto internationalization. While both .=T and 9A8A automatically use -=+"2&, " >"KK developers have to utilize the appropriate compiler switches to ensure that thischaracter set is used.

rror and ception andingrror messaging and eception handling must be part and parcel of all applications.

An eception differs from an error since the former is typically the result of an un/contemplated situation. With this in mind eceptions should never be used torepresent errors. )ost often errors represent recoverable problems while eceptionscould often be unrecoverable depending on its nature. +f this is the case then it isnecessary that the application fails securely. or instance, this could mean denyingservice even to legitimate users. An ecellent eample of this is a firewall. +f afirewall encounters an eception from which it cannot recover, it is best for it to failand block all traffic 3 thus failing securely 3 rather than failing open which wouldmean allowing all traffic to pass unregulated.

+mproper error and eception handling could help an attacker gain access toinformation that typically is not publicly available.

Dood error messages give notification that a problem occurred, an eplanation ofwhy the problem occurred, and a solution so that the user can fi the problem.Dood error message tet is specific, user/centered, clear, consistent, and courteous.

rror handling must be performed at every layer of the application. All errors mustbe sanitized and no sensitive information must be displayed in the client. &atabaseor application layer error message should also be intercepted and must not be

displayed back to the client. rror messages should be simple and concise. Theyshould never contain code snippets, S*' statements, detailed failure eplanations.Any information needed for debugging must be logged on the server side asdescribed later in this document. or eample an error message should never showa stack trace to a client. +f a valid user name but an invalid password is entered theerror message should never indicate that one of them was correct. $ather provideno information that could potentially aid an attacker in a brute force or other attack.


22/24

An error and eception handling framework must be implemented in everyapplication. Special care must be taken if an eception can occur when theapplication is running in elevated privilege mode. This is especially true when usingeception handlers. &evelopers must ensure that privilege downgrading whennecessary must be performed in the eception handler and not !ust in the try blocksince if an eception does occur the downgrade will not take place otherwise. Anefficient way to deal with this is to utilize the finally block supported by mostmodern programming languages.

vent 'oggingvent logs must be created since they not only aid in debugging but can also help inincident response and in identifying and recovering from an attack. 'ogs must beable to inform the reader who did what and how they did it. Application developersmust not rely on the web server or database server logging but must createapplication specific logs. nsure that no personal or confidential data is logged, forinstance the social security or credit card number of a customer.

'ogging Sources(erimeter devices 3 network events2perating System 3 System access and authentication detailsWeb Server 3 2S and implementation specific locationsApplication 3 (laced in variety of locations including 2S, Web, and implementationspecific&atabase 3 &atabase transactions and access+nformation that must be 'oggedThe following table lists the attributes that must be contained in the logs in additionto any application specific information:

'ogging (arameters&ate and Time-ser Account +nformation"aller +nformation and (arameter 8alues=etwork AddressSource "ode $eference 4where in the code the log was being generated5Application =ameApplication (arameters such as the current process and thread +&s.

Some of the above parameters may only be relevant in multi/processing or multi/

threaded applications.'ogging 'evelsThe following lists the recommended log levels that an application may use:

&ebug / or developer use only. Should be removed from production systems.+nfo / +nformational messages like usage statistics.Warning / (otential problems such as disk quota warnings.rror / rrors in the code.atal / ceptions in the code.


23/24

vents that must be 'oggedThe following lists the set of events classified based on function that must belogged:

Authentication / 'og success and failures along with user +&. (asswords mustnever be logged.-ser 'ogons-ser 'ogoffsService 'ogons=etwork 'ogonsAuthorization / 'og success and failures along with effective user +& and user+&.$esource Access+mpersonation Attempt(rivilege -se&elegationSession )anagementSession "reation / 'og time stamp when session was created as well as user

+& and session +& information.Session Termination / 'og time stamp when session was terminated.Session Timeout > piry / 'og the reason and time stamp information.-ser )anagementAccount "reation / 'og success and failure as well as the user +& of theadministrator performing the user management and time.Account &eletionAccount )odification(assword $eset / 'og the network address that is requesting the passwordreset.

Account 'ockout / 'og the reason e.g. multiple failed login attempts and thenetwork host responsible for the same.(assword "hange / 'og the time and network address of the host.$oles Assignment / 'og success and failure as well as the user +& of theadministrator performing the user management and time.&ata 8alidation+nvalid +nput &ropped / 'og the network address of the client issuing theinvalid input as well as the input itself.Application rrors and ceptionsStack Trace and "all Draph / 'og the data responsible for causing the error oreception and the state of the application when the error occurred. &o not log

sensitive information or large chunks of source code or static information.'oggingAttempts to change log levels / 'og this information in a different locationthen the default log.Attempts to delete log / This information can typically be obtained using theoperating system#s file system logs.'og 'ocations


24/24

&evelopers must adhere to the following guidelines with regards to the location towrite the logs:

Always log to persistent storage. The logging medium must if possible be aseparate hardened server which cannot be directly accessed even if theapplication were compromised. All communication to and from this log servermust be encrypted.

+f the volume of information being logged is not significant then developersare required to use the logging capabilities of the underlying operatingsystem. This is the vent 'ogs under Windows and the S0S'2D daemonunder -=+E.

+f a custom log file is used then the path of this file must be configurable bythe user and the A"'s over this file must be defined so that only applicationauthorized users can read > write to the file. 'ogs created must be archivedand backed up once a day and a new log file must be created. +t is alsorecommended to create multiple log files: one for normal events and another

for etraordinary occurrences'og 'ibraries

9A8A developers are encouraged to use the !ava.util.logging package and notto define their own custom logging A(+s. &evelopment groups are encouragedto develop reusable centralized logging components that are standardizedacross the group.

web app security standard

Documents