09030241129_web application security and standards

8/8/2019 09030241129_Web Application Security and Standards

1/12

Web Application

Security andStandards

Submitted By:

PRNo Name

09030241129 Reshma Wawhal

Submitted To:

Mr. Sameer Saxena

Submitted On:

4th Jan 2011


2/12

Web Application Security and Standards

2

Table of Contents

Web Application Security and Standards ................................ ................................ ........................... 3

Web Applications ................................ ................................ ................................ .......................... 3

Why Web Application Security Is Different Than Host and Network Security? ............. ............. .... 3

The Web Application Security Lifecycle ................................ ................................ ........................ 4

Secure Development ................................ ................................ ................................ .................. 4

Secure Deployment ................................ ................................ ................................ .................... 4

Secure Operation................................ ................................ ................................ ........................ 5

Adoption of Standard across Organization ................................ ................................ ..................... 5

Some of global standards and Compliance ................................ ................................ ..................... 9

Conclusion................................ ................................ ................................ ................................ ... 11

Reference ................................ ................................ ................................ ................................ .... 12


3/12


3


Web Applications

Any web application is combination of front -

end which is visible to end user and back-endwhich operates in the back-end which not

visible to end user i.e. database and various

transactions. Now, web application is accessedvia web browser over a network it can be

internet or intranet.

Why Web Application Security Is

Different Than Host and Network

Security?

If we see the OSI Protocol layer, it anapplication layer which comes on top and

when user wants to communicate to anotheruser , they uses an application like sending e-mail, or wants to do online shopping he usesweb browser to open that website. If any

hacker wants to attack he will use web

application or browser thats why security ofweb application is very important.

When securing enterprise applications, that

typically involve locking down the platform,securing communications, authenticatingusers, and implementing security controls

provided by the application platform.

On other host security is securing end-usercomputer by anti-virus, firewall, anti-malware,and securing operating system becomes veryimportant.

Network security consists of the provisionsand policies adopted by the network

administrator to prevent and monitor

unauthorized access, misuse, modification, ordenial of the computer network and network-accessible resources

Other major factors are:

y Browser UI: As we know about webapplication, as its user interface its really

difficult to control. Browser which interactswith other applications at the same time.

The browser may be used by a hostile

party, or have been compromised by a thirdparty. There is also a huge variety in web browsers- each comes with different

vulnerabilities, rendering and code

interpretation engines, and securityfeatures. As if now most secure browser is

opera.y Custom code equals custom

vulnerabilities: As we do applicationcoding for developing an application there

can some programming errors may

developers dont consider and that leads to

vulnerabilities. SANS Top 25 programmingerrors tell about errors and how to tackle

them.

y Firewalls/shielding alone cant protectweb applications: When we experiencesoftware vulnerabilities with our enterprise

software, from operating systems, todesktop applications, to databases and

everything else, we use tools like firewalls

and IPS to block attacks while we patch the

vulnerable software. This shield-then-patchmodel has only limited effectiveness for

web applications. A web application

firewall (WAF) cant protect you fromlogic flaws. While WAFs can help with

certain classes of attack, out of the box they

dont know or understand your applicationand thus cant shield custom vulnerabilities

they arent tuned for.y Reliance on frameworks/platforms: We

rarely build our web applications from the

ground up from shiny new C code. We arechallenged to secure and deploy thesepieces as well as the custom code we build

with them. In many cases we createsecurity issues through unintended uses of

these components or interactions between

multiple layers due to the complexity of theunderlying code.

y Heritage (legacy) code: Even if we wereable to instantly create perfectly secure

code from here on forward, we still havemassive code bases full of oldvulnerabilities to analyze and perhaps fix.If older code is in active use, it needs just

as much security as anything new wedevelop. With links to legacy systems,

modification of older applications often

ranges from impractical to impossible,

placing the security burden on the newerweb application.


4/12


4

y New vulnerability classes: As withstandard applications, researchers and badguys are constantly discovering new classesof vulnerabilities. For example, using Flash

to spy on user activities and pushing code

into back-end databases are threat types

unseen before web applications. In the caseof the Web, these often affect nearly every

web site on the face of the planet themoment they are discovered. Even if wewrite perfect code today, theres nothing to

guarantee it will be safe tomorrow.

The Web Application Security Lifecycle

While web applications present different

challenges, additional steps to address these

issues arent radical deviations from what you

likely do today.

Figure 1 Web Application Security Lifecycle

Secure Development

Process and Training: This sections focus is

on building security into the software

development lifecycle (SDLC). It includes

training for people who deliver web

applications and improved processes to guide

their activity. Security awareness training is

managed through education and supportive

process modifications, as a precursor to

making security a functional requirement of

the application. We will also review tools that

automate portions of the effort: static analysis

to aid engineering in identifying vulnerable

code, and dynamic analysis to detect

anomalous application behavior.

y Secure SDLC: Introducing securedevelopment practices and softwareassurance into the web application

programming process.

y Static Analysis: Tools that scan the sourcecode of an application to look for security

errors. Often called white box tools.

y Dynamic Analysis: Tools that interact witha running application and attempt to break

it, but dont analyze the source code

directly. Often called black box tools.

Secure DeploymentAt the stage where an application is code-

complete, or is ready for more rigorous testingand validation, it is time to confirm that it

doesnt suffer from serious known security

flaws, and is configured such that it is notsubject to any known compromises. This is

where we start introducing vulnerability

assessments and penetration testing - along

with their respective approaches toconfiguration analysis, threat discovery, patch

levels, and operational consistency checking.

y Vulnerability Assessment: Scanning theweb application with automation tools e.g.IBM Rational AppScan, Acunetix and

performing manual test with or without

credentials to find vulnerabilities.

y Penetration Testing: Penetration testing isthe process of actually breaking into anapplication to determine security

vulnerabilities and the risks they pose.

While vulnerability assessments findsecurity flaws, penetration tests research

those holes to measure impact and while

vulnerability appraisals find security flaws, penetration runs explore those holes to

measure impact. May be a product, service,or both.

Most people do not trust developers to

thoroughly test their own code. They are

incentivized to develop and release newfeatures, not rigorously test and prove stable

functionality. Testing of code often isconducive to a different mindset, and has


5/12


5

evolved to include a specialized set of skills

and tools to cope with the scope required toactually verify function. Security should be

considered in the same light: we need thedevelopment team to understand the security

issues, and should alter development processesto enable them to develop secure code and test

cases to verify their code, but their efforts also

need to be validated externally.

Secure Operation

In this section we move from preventative

tools and processes to those which provide

detection capabilities and can react to events

from an operational application. Our primary

focus is on web application firewalls ability to

screen an application from unwanted uses, and

monitoring tools that scan requests for

inappropriate activity against the application

or associated components. Recent

developments in detection tools promote

enforcement of policies, react intelligently to

events, and combine multiple services into a

cooperative hybrid model.

y Web Application Firewalls: Networktools that monitor web application traffic

and alert on or attempt to block - known

attacks.

y Application and Database ActivityMonitoring: Tools that monitor application

and database activity (via a variety of

techniques) for auditing, and generate

security alerts based on policy violations.

As many organizations are just starting to

come to terms with application security, we

will map out a framework and illustrate the

options so web development organizations can

start looking at the whole picture. We need to

stress that we are only providing an overviewof available options, and a basic introduction

to how they work and where they fit in. While

we discuss what technologies and methods

you should consider, the details on how

could encompass several books. Web

application security is a field undergoing rapid

advancement - almost as fast as the bad guys

come up with new attacks.

Adoption of Standard across

Organization

Web applications that process sensitive or

curtailed info must follow the control

requirements. Sensitive and Restricted data are

prohibited from being stored persistently on

Internet accessible (i.e., public facing) web

servers.

Examples of data that would typically be

classified as Sensitive include:

y Protected Health Informationy Customers Informationy Financial Informationy Drivers license numbers or Social Security

numbers

Examples of data that would typically be

classified as Restricted include:

y Transactionsy Transactions covered by non-disclosure

agreements

Standards are:

y Server Configuration and Access Controlo No unused files are to be left on a

production web server.o Development should not be performed

on the production web server. Test

environments must be provided.

o File permissions should use the leastpermission principle.

o Minimum privilege should be given tothe web server account.

o Do not grant write access within theweb root to users.

o Only grant execute permission on filesthat require it.

o Static HTML pages must not haveexecute permissions available.

o Disable directory viewing on the webserver itself.

o For web applications that requireauthentication, ensure that all resources

recheck credentials.


6/12


6

o DNS aliases will be used to accessapplications. The server name is not to

be used for user access.

y Authenticationo All authentications must use

transmission encryption.

o Do not make logon or authenticationcookies persistent.

o Log each instance of logins at aminimum of 30 days or as required by

applicable legal requirements.

o Perform data validation on bothpassword and username form fields

o Do not hard code the database name,username, or hostname into the

application itself.

o Where possible, use a directory servicefor authentication.

o For applications that do not use LDAPauthentication, user accounts will be

locked after 60 days of inactivity.

o Back end servers will verify the identityof the requesting web server.

y Data Validation: All data input must bevalidated on the server side. Client side

validation is encouraged but not meant to

be the sole control for data input validation.The only sustainable strategy for data

validation is ACCEPTING KNOWN

GOOD DATA. The other options require

constant maintenance and thus will not be

expounded upon in this standard.

y Database Interfaceso Store database names, usernames,

passwords, and hostnames in a resource

outside of the code base.

o Publicly classified data may be hostedon a single tier web application.Internal, confidential, and confidential/

high risk data must be served on a

multitier web application.

o Use database engines that only allowsecurity permissions down to an

individual database object.

o Web accounts must use a dedicatedaccount that is not a default database

account. These accounts must not have

administrative privileges on the

database.

y Authenticated Session Managemento Never accept chosen session IDs.

Always generate a new session ID for

each new login request.

o Assign a new session ID after successfullogin for applications that require

authentication.

o Use session IDs that is random and notsequential in nature with a minimum of

10 alphanumeric characters.

o Use session IDs generated by theengine you are using if applicable.

o Use encryption to protect theauthenticated Session ID in transport

from server to client.

o Session data shall not identify a user orindividual.

o Servers destroy the session relatedinformation at logout.

o Regarding timeouts for browserinactivity:

All applications will implement asecurity timeout feature. Timeouts

will be set to the lowest possiblelevel balancing the need to protect

sensitive data with the usability of

the application. Users will be warned

(typically 25 minutes) before the

session is set to expire and given the

opportunity to extend their session.

Applications will limit access tosensitive and confidential data to

users who need to know and access

that data. Where possible,

applications will challenge users tovalidate their credentials beyond the

initial application login when

accessing confidential data.

o Applications will preserve user work indraft status before expiring the users

session so data entry is not lost.

Alternately, the application may engage

a secure screen saver that challenges the


7/12


7

user to validate credentials upon re-

accessing the application.

Protect Against Common Web Application

Exploits: Web applications should be

developed to prevent common exploits.

Common exploits and programming errors arelisted by several reputable organizations,

including OWASP and SANS.

Some of Common Vulnerabilities are:

Session high-jacking

By taking advantage of a cookie that was not

deleted, a malicious individual may attempt to

gain access to a valid user by manipulating

that lost cookie and using it to impersonate the

innocent user that was not even aware that aunsecured cookie was left behind. Using

cookies must be avoided as much as possible,

whenever possible.

Cookies must always have a timeout parameter

so they dont just sit on someones computer

forever (or until manually deleted). The

remember me option should be used

sparingly and consciously as well as requiring

a new login to access critical personal data.

An alternative to using cookies is enabling aSQL Session State server, which stores the

session details on a secured SQL server. Users

should also be always able to logout of their

sessions, to avoid it still being active as

someone else uses that browser, or computer.

Blind SQL Injection

Blink SQL injection may also relate to

Insufficient Validation but may also be a

subject on its own. A malicious user, either by

knowledge or by trial and error, attempts the

following line on the login form:

Username = administrator

Password = or 1=1 - and userpass=

Then, by luck, hes able to login as

administrator and is free to do any type of

damage he/she wishes.

Besides of adding validation scripts on both

the server-side and client-side (Insufficient

Validation) a good way to prevent injections is

to sanitize the code before sending it to the

SQL server.

A way to sanitize the parameters is using theTRIM method of both SQL - for stored

procedures - and C#.Net or VB.Net.

Also, instead of using simple query string,

using SQL parameters, so that any additional

input will be cleaned up before being sent to

the server.

Cross-site Scripting (XSS)

Cross-site Scripting (XSS) takes advantage of

dynamically generated Web pages. In an XSSattack, a Web application is sent with a script

that activates when it is read by an

unsuspecting users browser or by an

application that has not protected itself against

cross-site scripting. Because dynamic Web

sites rely on user input, a malicious user can

input malicious script into the page by hiding

it within legitimate requests.

A malicious user that knows of this

vulnerability in a site may attempt to gain

controls of an end-user and steal information

from their computer.

An important way of preventing this attack is

by avoiding the use of frames or too many

JavaScript popups.

HTML Comments

Comments in your code are great for

development. Nevertheless, they can also

teach a malicious user how the site works and

potentially hint away structural information or

even critical credential information.

Besides, viewing a web pages source is just as

hard as clicking on view source. Or, if using

a prompt window, the webpage is not

rendered, and all the text comes out just as

plain as day.


8/12


8

Therefore, before publishing a site its

important to review any comments that might

be present in the pages, so that it does not

contain any information that may aid a

malicious user

One tier Approach

Its very common to have a ONE person web

agency working on a project for a market since

these agencies tend to be the cheapest and the

most dynamic. Nevertheless, most times, these

agencies, for the sake of time, do not

implement the most basic security standards.

By using only one tier, a malicious user may

attempt all kinds of attack and attempt to gain

as much knowledge as possible from the errors

returned, the data, and processes (traces, logs,

etc)

Having the web application code access data

directly from the DB is dangerous. The three-

tier/mid-tier or MVC standard is

recommended: Data Layer, Business Layer,

and Presentation Layer

For that reason, its always better (and sound)

to separate the web application in layers, not

only to increase security but to promote

reusability, as the one layer may be

implemented in other projects if not fully

coupled into a specific application.

InsufficientValidation

Using the same example from the Blind SQL

injection, if theres no validation on the client

side, then once the malicious user clicks on

send then the server will attempt to interpret

the login information and may end up either

throwing an error or worse, return the result

like the malicious user expected.

Therefore, using REGEX (regular expressions)

along with javascript on the client-side and

REGEX on the server-side can double the

changes that an error or malicious activity can

be caught before it causes any damage.

No custom Errors

When a page returns an unhandled error, a

.NET error page appears and may disclose

more information than intended. A malicious

user may use this information to gain access to

other data, or even deface the site.

Therefore, using the tag


9/12


9

Therefore, avoid using hidden values as much

as possible.

Some of global standards and

Compliance

Some global standards are:

y ISO 27001y PCIy W3Cy HIPAAy SOXy COBITy GLBAInternational Organization for

Standardization 27001 Compliance

The ISO/IEC 27000-series (also known as the

'ISMS Family of Standards' or 'ISO27k' for

short) comprises information security

standards published jointly by the International

Organization for Standardization (ISO) and the

International Electro technical Commission

(IEC).The ISO 27001 standards was published

in October 2005, essentially replacing the old

BS7799-2 standard. It is the specification for

ISMS, an Information Security Management

System

ISO 27001 enhanced the content of BS7799-2

and harmonized it with other standards.

The objective of the standard itself is to

"provide a model for establishing,

implementing, operating, monitoring,

reviewing, maintaining, and improving an

Information Security Management System".

Regarding its adoption, this should be a

strategic decision. Further, "The design and

implementation of an organization's ISMS is

influenced by their needs and objectives,

security requirements, the process employed

and the size and structure of the organization".

The series is deliberately broad in scope,

covering more than just privacy,

confidentiality and IT or technical security

issues. It is applicable to organizations of all

shapes and sizes. All organizations are

encouraged to assess their information security

risks, and then implement appropriate

information security controls according to

their needs, using the guidance and

suggestions where relevant. Given the

dynamic nature of information security, the

ISMS concept incorporates continuous

feedback and improvement activities,

summarized by Deming's "plan-do-check-act"

approach, that seek to address changes in the

threats, vulnerabilities or impacts of

information security incidents.

Payment Card Industry Data Security

Standard

The PCI DSS, a lay of Payment account data

security comprehensive requirements for

enhancing, was developed by the founding

payment brands of the PCI Security Standards

Council, including American Express,

Discover Financial Services, JCB

International, MasterCard Worldwide and Visa

Inc. Inc. International, to help facilitate the

broad adoption of consistent data security

measures on a global basis.

For security management, policies,

procedures, network architecture, softwaresystem contrive the PCI DSS is a multifaceted

security standard that includes requirements

and the PCI DSS is a multifaceted security

standard that includes requirements for

security management, policies, procedures,

network architecture, software contrive. To aid

organizations proactively protect customer

account data this comprehensive standard is

intended.

The PCI Security Standards Council will

enhance the PCI DSS as needed to ensure that

the standard includes any new or modified

requirements necessary to mitigate emerging

payment security risks, while continuing to

foster wide-scale adoption.

For feedback from the advisory board ongoing

development of the standard will supply and


10/12


10

ongoing development of the standard will

furnish for feedback from the advisory board.

All key stakeholders are encouraged to supply

input, during the creative activity and re-

examine of proposed additions or all key

stakeholders are encouraged to furnish input,

during the creation and re-examine of

proposed additions.

The core of the PCI DSS is a group of

principles and accompanying requirements,

around which the specific elements of the DSS

are organized:

y Vulnerability Management Programy Implement Strong Access Controly Measures Regularly Monitor and Test

Networksy Maintain an Build and Maintain a Secure

Network

y Protect Cardholder Datay Maintain Information Security PolicyHealth Insurance Portability and

Accountability Act Compliance

HIPAA Compliance are designed to provide

safe & protected electronic health records and

a national healthcare network for transmitting

patient information throughout the healthcareindustry to provide countless benefits to

healthcare professionals and especially to

patients.

The Privacy Rule pertains to all Protected

Health Information (PHI) including paper and

electronic, the Security Rule deals specifically

with Electronic Protected Health Information

(EPHI). It lays out three types of security

safeguards required for compliance:

administrative, physical, and technical.

Sarbanes-Oxley Act

The Sarbanes-Oxley Act of 2002, also known

as the Public Company Accounting Reform

and Investor Protection Act of 2002 and

commonly called Sarbanes-Oxley, SOX, is a

United States federal law enacted on July 30,

2002 is designed to protect investors by

improving the accuracy and reliability of

corporate disclosures made in accordance with

securities laws.

This new standard requires going beyond

monitoring security events from the networklevel. Now you should monitor and secure

compliance-related data and applications

throughout your enterprise by monitoring at

both the application level and network activity

level. Monitoring user activity is particularly

important for maintaining separation of duties,

and most important of all, for adopting a true

policy-driven security program

Control Objectives for Information and

related Technology

COBIT provides good across a domain &

process framework and presents activities in a

manageable and logical structure. COBITs

good practices represent the consensus of

experts. They are strongly focused more on

control, less on execution. These practices will

help optimise IT enabled Investment, ensure

service delivery and provide a measure against

which to judge when things do go wrong.

The COBIT control framework contributes tothese needs by:

y Making a link to the business requirements.y Organizing IT activities into a generally

accepted process model.

y Identifying the major IT resources to beleveraged.

The business orientation of COBIT consists of

linking business goals to IT goals, providing

metrics and maturity models to measure their

achievement, and identifying the associatedresponsibilities of business and IT process

owners.

Gramm-Leach-Bliley Act Compliance

The Financial Modernization Act of 1999, also

known as the "Gramm-Leach-Bliley Act" or

GLB Act, includes provisions to protect


11/12


11

consumers personal financial information

held by financial institutions. It requires

financial institutions to develop, implement,

and maintain a comprehensive written

information security program that protects the

privacy and integrity of customer records

there are three principal parts to the privacy

requirements: the Financial Privacy Rule,

Safeguards Rule and pretexting provisions.

The safeguards rule necessitates financial

institutions to develop an indicted info security

plan that describes how the company is

prepared for, and the safeguards rule requires

financial institutions to develop a pended info

security plan that describes how the company

is prepared for and plans to continue to protect

clients non-public personal information.

Financial institutions to evolve beyond point

security merchandises banking regulators now

necessitate. You now must employ an

integrated security strategy that establishes

perimeter security as well as security inside

the network and among all databases,

applications, and end-point devices such as

laptops, PCs, wired and wireless devices,

PDAs, and more. All devices on your network

must:

y Collaborate to ensure proactive security isworking effectively.

y Adapt in real-time to your institutionschanging risk profile and new security

threat events as they occur.

Your financial institutions cant achieve this

proactive security culture without the help of

automated security compliance management

solutions that are integrated throughout your

users, databases, applications, and network toenable real-time monitoring of all activity.

You must have a logging, monitoring, and

incident response capability that will allow

you to prevent, detect, and respond rapidly in

real-time to internal and external threats.

Security Compliance Management for GLBA

With the continuous updates to the GLBA

information security mandates, your financial

institution must adopt a risk management and

security compliance strategy with the right

technology solutions that will help you:

y Establish best practice controlsy Continuously manage your risky Know when material events occury Lower your compliance costy Enable security compliancey Build accountability and trusty Protect customer datay Provide an ongoing and detailed audit and

forensic trail

Conclusion

Security of Website or Web Application isvery important because if security will not

there it will affect our stakeholders (customer,

employee, vendor etc.).

It builds trust among stakeholders and

organization if organizations web application

is compliant with standards mentioned above.


12/12

09030241129_web application security and standards

Documents