Information Security Guideline

marlinlineInternet και Εφαρμογές Web

31 Οκτ 2013 (πριν από 3 χρόνια και 11 μήνες)

109 εμφανίσεις


Information Security Guideline



Title

Web

Services

Guideline

Reference No

03
.09
.0
4

Version No

1

Status

Draft

Creation Date

June 4
, 200
9

Revision Date



Approval Date


Approved by



Key Words

Web
, Internet, Server
,
Application





Statement of Policy


Washington University School of

Medicine (WUSM) is committed to conducting business in compliance
with all applicable laws, regulations and WU policies. WUSM has adopted this policy to outline the
security measures required to protect electronic information systems and related equipment

from
unauthorized use.


Objective


The purpose of this guideline is to provide administrator
s

and user
s

advice on cho
o
s
ing,
implementing
, and
operating

Web

Service

technologies

in a secure manner
.

It is

meant to assist developers of
Web

application
s

in se
curing the generation
and reception of content and

to be a starting point for those who are
considering the implementation and development of
Web

services
.
Th
e guideline presents an o
verall
perspective of the components

that one must consider

to provide t
hese services securely in addition to an
introduction to the different technologies that provide the
Web

service.
The most efficient way to use this
document is to

become acquainted with the recommendations and guidance given followed up with the
availabl
e documentation provided by the vendor and/or
the
other references mentioned.



Definitions


Active Content
-

Refers to content on a
Web

site that is either interactive, such as Internet polls or opt
-
in
features, or dynamic, such as animated GIFs, stoc
k tickers, weather maps, JavaScript applications,
embedded objects, streaming video and audio or

ActiveX application
. Streaming video and audio rely on
browser plug
-
ins, such as RealPlayer, to display active content
.


Canonicalization

-

I
s the process that

determines how various equivalent forms of a name are resolved to a
single standard name
.


Content Generator


This is a

program, script or module

on a
Web

server tha
t will dynamically
generate
Hypertext

Markup L
anguage (HTML) pages for users.
Content g
enerators can range from simple Common
Gateway Interface (CGI) scripts executed by the
Web

server to Java EE or .NET application servers in
which most

if not all

HTML pages served are dynamically generated.


Mobile Code


I
s software obtained from remote s
ystems, transferred across a network, and then
downloaded and executed on a local system without explicit installation or execution by the recipient.
Examples of mobile code include scripts (JavaScript, VBScript), Java applets, ActiveX controls, Flash
anim
ations, Shockwave movies (and Xtras), and macros embedded within Office documents.


Pharming
-

Using technical means to redirect users into accessing a fake
Web

site masquerading as a
legitimate one and divulging personal information.


Phishing
-

Using so
cial engineering techniques to trick users into accessing a fake
Web

site and

divulging
personal information.



Information Security Guideline


Server Side Includes (SSI)
-

I
s a simple server
-
side scripting language used almost exclusively for the
Web
.
As its name implies, its primary use

is including the contents of one file into another one dynamically when
the latter is served by a
Web

server.


Tainted Checking
-

A

feature in some programming languages, such as Perl
, PHP and

Ruby, designed to
increase security by preventing malicious us
ers from executing commands on a host computer.


Tainted Variable


Any

scripted

variable that can be modified by an outside user that
poses a potential
security risk.


Web

Application


This is a
n application that is accessed via
Web

browser over a networ
k such as the
Internet or an intranet. It is also a computer software application that is coded in a browser
-
supported
language (such as HTML, JavaScript, Java, etc.) and reliant on a common
Web

browser to render the
application executable.


Specific Threa
ts t
o
Web

Servers and Services


There are numerous types of attacks to
Web

based applications and services.

More than 80% of successful

attack
s occur at the application layers.

The

detail
s

on these

types of attack can be found at

the
Web

Application Secu
rity Consortium

(WASC)

(
http://www.
Web
appsec.org/projects/threat/

) along wi
th other
important information.

These are categorized below:



Threat classification T
able


Authentication

Authorization

C
lient
-
side
Attacks

Cmd
Executions

Information
Disclosure

Logical
Attacks

Other

Brute Force

Credential/Session
Prediction

Content
Spoofing

Buffer
Overflow

Directory
Indexing

Abuse of
Functionality

Http Response
Splitting

Insufficient
Authentication

Insuff
icient
Authorization

Cross
-
site
Scripting

Format String
Attack

Information
Leakage

Denial of
Service

Web

Server/Application
Fingerprinting

Weak Password
Recovery
Validation

Insufficient Session
Expiration


LDAP
Injection

Path
Transversal

Insufficient
Anti
-
automation

Pharming


Session Fixation


OS
Commanding

Predictable
Resource
Location

Insufficient
Process
Validation

Phishing




SQL Injection







SSI Injection







XPath
Injection





It is important that

administrator
s and developers

know

and und
erstand

the threats to the application
s

and
services they provide.
It is only through this understanding that existing threats can be addresses in the
development,

configuration

and operation

of the service.

A brief discussion of these is merited to give

the
reader a background of the numerous type of attacks that can be used against them.

Authentication

Authentication

covers attacks that target a
Web

site's method of validating the identity of a user, service or
application. Authentication is performed u
sing at least one of three mechanisms: "something you have",
"something you know" or "something you are".




Brute Force


Information Security Guideline


A Brute Force attack is an automated process of trial

and error used to guess a person's
username, password, credit
-
card number or cryptographic key.



Insufficient Authentication

Insufficient Authentication occu
rs when a
Web

site permits an attacker to access sensitive content
or functionality without having to properly authenticate.



Weak Password Recovery Vali
dation

Weak Password Recovery Validation is when a
Web

site permits an attacker to illegally obtain,
change or recover another user's password.



Authorization

Authorization
covers attacks that target a
Web

site's method of determining if a user, service,

or application
has the necessary permissions to perform a requested action. For example, many
Web

sites should only
allow certain users to access specific content or functionality. Other times a user's access to other resources
might be restricted. Using
various techniques, an attacker can fool a
Web

site into increasing their
privileges to protected areas.




Credential/Session Prediction

Credential/Session
Prediction is a method of hijacking or impersonating a
Web

site user.



Insufficient Authorization

Insufficient Authorization is when a
Web

site permits access
to sensitive content or functionality
that should require increased access control restrictions.



Insufficient Session Expiration

Insufficient Session Exp
iration is when a
Web

site permits an attacker to reuse old session
credentials or session IDs for authorization.



Session Fixation

Session Fixation is an attack techniq
ue that forces a user's session ID to an explicit value.



Client
-
side Attacks

Client
-
side attacks focus

on the abuse or exploitation of a
Web

site's users. When a user visits a
Web

site,
trust is established between the two parties both technologically an
d psychologically. A user expects
Web

sites they visit to deliver valid content. A user also expects the
Web

site not to attack them during their
stay.

By leveraging these trust relationship expectations, an attacker may employ several techniques to
explo
it the user.




Content Spoofing

Content Spoofing is an attack technique used to trick a user into believing that certain content
appearing on a
Web

site is legitimate an
d not from an external source.



Cross
-
site Scripting

Cross
-
site Scripting (XSS) is an attack technique that forces a
Web

site to echo attacker
-
supplied
executable co
de, which loads in a user's browser.



Command Execution


Command Execution
covers attacks designed to execute remote commands on the
Web

site. All
Web

sites
utilize user
-
supplied input to fulfill requests. Often these user
-
supplied data are used to create

construct
commands resulting in dynamic
Web

page content. If this process is done insecurely, an attacker could
alter command execution.




Buffer Overflow

Buffer Overflo
w exploits are attacks that alter the flow of an application by overwriting parts of
memory.



Format String Attack


Information Security Guideline


Format String Attacks alter the flow of an applica
tion by using string formatting library features
to access other memory space.



LDAP Injection

LDAP Injection is an attack technique used to exploit
Web

sites that constru
ct LDAP statements
from user
-
supplied input.



OS Commanding

OS Commanding is an attack technique used to exploit
Web

sites by executing Operating System
commands through m
anipulation of application input.



SQL Injection

SQL Injection is an attack technique used to exploit
Web

sites that construct SQL statements from
user
-
supplied input.



SSI Injection

SSI Injection (Server
-
side Include) is a server
-
side exploit technique that allows an attacker to
send code into a
Web

application, which will later be executed
locally by the
Web

server.



XPath Injection

XPath Injection is an attack technique used to exploit
Web

sites that construct XPath queries from
user
-
supplied input.



Info
rmation Disclosure

Information Disclosure

covers attacks designed to acquire system specific information about a
Web

site.
System specific information incl
udes the software distribution
s
,
version numbers, and patch levels. Or the
information may contain th
e location of backup files and temporary files. In most cases, divulging this
information is not required to fulfill the needs of the user. Most
Web

sites will reveal a certain amount of
data, but it's best to limit the amount of data whenever possible. Th
e more information about the
Web

site
an attacker learns, the easier the system becomes to compromise.




Directory Indexing

Automatic directory listing/indexing is a
W
eb

server function that lists all of the files within a
requested directory if the normal base file is not present.



Information Leakage

Information Leakage is when a

Web

site reveals sensitive data, such as developer comments or
error messages, which may aid an attacker in exploiting the system.



Path Traversal

The Path Traversal atta
ck technique forces access to files, directories, and commands that
potentially reside outside the
Web

document root directory.



Predictable Resource Locatio
n

Predictable Resource Location is an attack technique used to uncover hidden
Web

site content
and functionality.



Logical Attacks

Logical Attacks focus

on the abuse or exploitation of a
Web

application's logic flow. Application logic is
the expected pro
cedural flow used in order to perform a certain action. Password recovery, account
registration, auction bidding, and eCommerce purchases are all examples of application logic. A
Web

site
may require a user to correctly perform a specific multi
-
step proces
s to complete a particular action. An
attacker may be able to circumvent or misuse these features to harm a
Web

site and its users.




Abuse of Functionality

Abuse
of Functionality is an attack technique that uses a
Web

site's own features and functionality
to consume, defraud, or circumvents access controls mechanisms.



Denial of
Service

Denial of Service (DoS) is an attack technique with the intent of preventing a
Web

site from
serving normal user activity.


Information Security Guideline




Insufficient Anti
-
automati
on

Insufficient Anti
-
automation is when a
Web

site permits an attacker to automate a process that
should only be performed manually.



Insufficient Process

Validation

Insufficient Process Validation is when a
Web

site permits an attacker to bypass or circumvent the
intended flow control of an application.



All of the existing attacks against
Web

services and appl
ication
s

can be summarized above
. For those

interested in the details of these attacks the WASC has published the

Threat Classification Guide


that
discusses each threat in some detail.

Most of the information provided above is from the
guide.
The
WASC
Web
site (
http://www.
Web
appsec.org
) is an excellent source of
best practice

information

for
Web

services.


GUIDELINE

Protecting a
Web

server from compromise involves
several steps. Included are
hardening the underlying
OS,
securing the
Web

server and the
We
b

server application
s
. N
etwork

protections should also be
employed
to prevent malicious entities from dir
ectly attacking the
Web

server. In this document we will
focus on the former three.


Secure
the
Web

Server Operating System


Th
e first step in securi
ng a
Web

Server

is to hardening the underlying OS.
This has been discussed in
detail in a related INFOSEC document.
Refer to 03.03.01 Windows Server (2003) H
ardening Guideline

or
03.03.02 Unix/Linux Server Hardening Guid
e
line

to do this.


Securing the
Web

Server


Installing the
Web

Server

There are many instances of
Web

Server Software out there. Among the most popular are Apache and
Microsoft’s IIS. It is recommended that you use one of these products because of their maturity and
support.

The Center f
or Internet security has an excellent benchmark for securing IIS
(CIS_IIS_Benchmark_v1.0.pdf)

and Apache

(CIS_Apache_Benchmark_
v2.2.pdf)

at
http://www.cisecurity.org/benchmarks.html


Microsoft also

offers a detailed procedure for securing IIS
in
its documentation “Improving
Web

Application Security: Threats and Countermeasures

June 2003”
which
can be found at
http://msdn.microsoft
.com/en
-
us/library/aa302432.aspx

.

It is strongly rec
ommended
that you consider them

as you install these services.


Vi
sit the manufacturer’s
Web

site or a vulnerability database
Web

site, such as the National Vulnerability
Database (NVD)

at
http://nvd.nist.gov/

, to determine whether there are known vulnerabilities and related
patches available that should be installed or configured as part of the setup process.


A
s in the case of Operating System

installation a

part
ially configured and/or patched
Web

server should not
be exposed to external networks (e.g., the Internet) or external users.


The
overarching principle, as describe in hardening the OS
, is to install only the
Web

services required for
the
Web

server and t
o elim
inate any known vulnerabilities
through patches or upgrades

and configuration
.
Any unnecessary applications, services, or scripts that are installed should be removed immediately once
the installation process is complete. During the installation of t
he
Web

server, the following steps should be
performed:





Install the
Web

server software either on a dedicated host or on a dedicated guest OS if
virtualization is being employed.




Apply any patches or upgrades to correct for known vulnerabilities.


Information Security Guideline




Cre
ate a dedicated physical disk or logical partition (separate from OS and
Web

server
application) for
Web

content.



Remove or disable all services installed by the
Web

server application but not required (e.g.,
gopher, FTP, remote administration).




Remove
or disable all unneeded default login accounts created by the
Web

server installation.




Remove all manufacturers’ documentation from the server.



Many
Web

servers and some other
Web

server software install sample scripts or executables
during the installa
tion process. Many of these have known vulnerabilities and should be removed
immediately.

Remove all example or test files from the server, including scripts and executable
code.



Apply
the
appropriate security template or hardening script to
the
server

w
here applicable
.
Microsoft has security templates that can be used for system
s

providing
Web

services.




Reconfigure HTTP service banner (and others as required) not to report
Web

server and OS type
and version (this may not be possible with all
Web

servers
).

This is discuss
ed

in more detail
below.


C
onsider installing the
Web

server with non
-
standard directory names, directory locations, and filenames.
Many
Web

server attack tools and worms targeting
Web

servers only look for files and directories in their

default locations. While this will not stop determined attackers, it will force them to work harder to
compromise the server, and it also increases the likelihood of attack detection because of the failed attempts
to access the default filenames and direc
tories and the additional time needed to perform an attack.


Configuring Access Controls

It is important to set identical permissions for both the OS and
Web

server application; otherwise, too much
or too little access may be granted to users.
Consider th
ese two point
s

wh
en configuring access controls;

(1) Limit the access of the
Web

server application to only the necessary
computational resources and (2)
Limit the access of users through additional access controls enforced by the

Web

server, where more
gr
anular

level
s of access control can be configured
.

Both these support the security principle of Least
Privileges.


A
dministrators should consider how best to configure access controls to protect information stored on
public
Web

servers by observing the fo
llowing recommendations.




U
se the
Web

server OS to limit which files can be accessed by the
Web

server’s service processes.
These processes should have read
-
only access to those files necessary to perform the service and
should have no access to other file
s, such as server log files
. Use
the
Web

server host OS access
controls t
o limit access to

the following
:


o

Application software and configuration files

o

Files related directly to security mechanisms:



Password hash files and other files used in authentica
tion



Files containing authorization information used in controlling access



Cryptographic key material used in confidentiality, integrity, and non
-
repudiation services

o

Server log and system audit files

o

System software and configuration files

o

Web

conten
t files





It is vital that the
Web

server application executes only under a unique individual user and group
identity with very restrictive access controls. New user and group identities should be established
for exclusive use by the
Web

server software.




Service processes should be

configured to run as a user with a strictly limited set of privileges
(i.e., not running as root, administrator, or equivalent).
On Linux/Unix hosts, the code should not
run with suid (set
-
user
-
id).


Information Security Guideline




Ensure only processes autho
rized for
Web

s
erver administration can write
Web

content files.



Most
Web

server software vendors provide directives or commands that allow the
Web

administrator to restrict user access
strictly
to public
Web

server content files.

Content files
should on
ly need be read by the user and

not written by service processes.

Take into consideration
some of the
additional safeguards below:


o

Have separate p
ublic and restricted areas.
Dedicate a single hard drive or logical
partition for
Web

content and establish

related subdirectories exclusively for
Web

server
content files, including graphics but excluding scripts

and other programs.

o

Define a single directory tree exclusively for all external scripts or programs executed as
part of
Web

content (e.g., CGI,
Act
ive Server Page [ASP], PHP).
Script files (e.g., ASP,
PHP, and PL) should have separate folders. It may also be beneficial to store the scripts
in a folder with a non
-
obvious name (e.g., not “Scripts”) to make it more difficult for an
attacker to find the

scripts through direct browsing.

o

Disable the execution of scripts that are not exclusively under the control of
administrative accounts. This action is accomplished by creating and controlling access to
a separate directory intended to contain authorized

scripts.

o

Executable files (e.g., CGI, .EXE, .CMD, and PL) should be placed in separate folders.
No other readable or writable documents should be placed in these folders.

o

Writable files should be identified and placed in separate folders. No script file
s should
exist in writable folders.

o

Include files (e.g., INC, SHTML, SHTM, and ASP) created for code reusability should
be placed in separate directories.
Server Side Includes (
SSI
)

should not generally be used
on public
Web

servers. ASP include files sho
uld have an .asp extension instead of .inc.
Note that much of the risk with include files is in their execute capability. If the execute
capability is disabled, this risk is drastically reduced.

o

Disable the use of hard or symbolic links.

The code should
use explicit path names when
invoking external programs.


o

Define a complete
Web

content access matrix. Identify whi
ch folders and files
should be
restricted and which should be accessible (and by whom).

o

In most cases
Web

Server file directory listings sh
ould be disabled




The
Web

server application should only

write
Web

ser
ver log files. The

log files should
not be
read by the
Web

application. Only root/system/administrative level processes

should

read
Web

server log files. Log files should be

stored in
a location that is sized appropriately. Ideally, log
files should be stored on a separate partition. If an attack causes the size of the log files to increase
beyond acceptable limits, a physical partition helps ensure the
Web

server has enough resources t
o
handle the situation appropriately
.



Temporary files created by the
Web

server application, such as those that might be generated in
the creation of dynamic
Web

pages or

by users uploading content, should be

restricted to a
specified and appropriately pr
otected subdirectory (if possible).

Place

a limit on the amount of
hard drive space that is dedicated for uploads, if uploads to the
Web

server are allowed. Ideally,
uploads should be placed on a separate partition to provide stronger assurance that the h
ard drive
limit cannot be exceeded.

Keep a
ccess to any temporary files created
by the
Web

server
application limited to the
processes that created the files (if possible).



E
nsure that the
Web

server

application cannot write

(or, in some cases, read) files

outside the
specified file structure dedicated to public
Web

content. Ensure that such directories and files
(outside the specified directory tree) cannot be accessed, even if users perform direct browsing by
accessing the URLs of those files or through
directory traversal attacks against the
Web

server
process.



Web

document markup languages frequently use URI references

(Refer to RFC3986)

in places
where they need to point to other resources, such as to external do
cuments or to specific portions
of the s
ame

document
.
Ensure that no publicly served
Web

content includes sensitive URIs
hidden in the source code. Many attackers and malicious bots search the source code for sensitive

Information Security Guideline


URI information, including, E
-
mail addre
sses, Images on other servers, link
s to other servers,
p
articular text expressions (e.g., userid, p
assword, root, administrator), h
idden form values
Hyperlinks.



Web

administrators who wish to limit bots’

(MSNbot, Slurp Googlebot, Mediabot,
Hyperlink,
etc.)
actions on their
Web

server need
to create a plain text file named “robots.txt.” The file must
always have this name, and it must reside in the
Web

server’s root document directory. In
addition, only one file is a
llowed per
Web

site. Note that t
he robots.txt file is a standard that is
vol
untarily support
ed by bot programmers, but

malicious bots (such as EmailSiphon and Cherry
Picker) often ignore this file.



Reduce the lifetime of sessions to mitigate the risk of session hijacking and replay

attacks. The
shorter the
session, the less time a
n attacker has to capture a session

cookie and use it to access
your application
.

Set
network connection timeouts (the time after which an inactive connection is
dropped) to
a minimum acceptable time limit.
TCP will tear down legitimate e
stablished
connec
tions

when the session is finished
, opening up new connections to legitimate users. If
possible limit the number of simultaneous connections to help protect against a Denial of Service
Attack
s
.


Securing
Web

Content


The security of the content is one of
the most overlooked aspects of securing the service.

Information
Security Policy prohibits the publishing of protected or confidential information without the proper
controls in place.
Therefore it is essential to understand how to protect the content wh
ile it is being
stored, processed and delivered.
It is also recommended that the following types of information be
eliminated or limited from the available content provided to the public unless there is a legitimate
business reason:





Internal personnel r
ules and procedures



Sensitive,

proprietary

(Confidential) or Protected

I
nformation
.
Do not store or have this
content in DMZ Web servers.




Personal inf
ormation about an WUSTL

personnel or users



Telephone numbers, e
-
mail addresses or general listings of
staff unless nec
essary to fulfill
WUSTL

requirements



Schedules of WUSTL

principals or their exact location (whether on or off the premises)



Information on the composition or preparation of hazardous materials or toxins



Sensitive information relating to
homeland security



Investigative

or legal

records



WUSTL’s

physical and information security procedures



Information about WUSTL

network
s

and information system infrastructure



Information that specifies or implies physical security vulnerabilities



Plans,

maps, diagrams, aerial photographs, and architectural plans of organizational building,
properties, or installations



Information on disaster recovery or continuity of operations plans except as absolutely
required



Details on emergency response procedure
s, evacuation routes, or organizational personnel
responsible for these issues



Copyrighted material without the written permission of the owner



Privacy or security policies that indicate the types of security measu
res in place to the degree
that
they may
be useful to an attacker.


Active Content

Active content refers to interactive program elements downloaded to the client (i.e., a
Web

browser) and
processed there instead of the server.
There are a variety of risks associated with active content and while

most of the active content technologies provide a useful capability many of them can be exploited by an
attacker.

These are mentioned below so administrators and developers can be aware of how Active Content

Information Security Guideline


plays a role in the compromise of client syste
ms. Though this guideline is primarily focused on the server
side one should be aware that delivery of active content

by the server

to the client

is often the vector of
infection.





PostScript


This is
one of the earliest examples of active content still

in use. The language
defines
primitives

for file manipulation which can be abused. Some postscript interpreters can be
set to disable potentially harmful
primitives
which should be used.



Java

-

Java is a full
-
featured, object
-
oriented programming lang
uage compiled into platform
-
independent byte code executed by an interpreter called the Java Virtual Machine (JVM).

Ensure
that the Java application is sandboxed

b
y

properly configuring the Java Security Manager.
The
Java security manager can limit a var
iety of activities, such as inspecting or changing files on a
client file system, using network connections, or even restricting what class libraries the code may
access. The Java security manager is flexible and can be configured for any application, prov
iding
additional security protections beyond those provided by the OS
. Be aware that Hostile Applets
can still pose
a
security threat even if executed within the sandbox
.



Javascript

-

JavaScript is a general
-
purpose scripting language available in most
We
b

browsers.
Each JavaScript interpreter supplies the needed objects to control the execution environment, and
because of differences the functionality can vary considerably. Within a browser context,
JavaScript does not have methods for directly accessing
a client file system or for directly opening
connections to other computers besides the host that provided the content source. Moreover, the
browser normally confines a script’s execution to the page in which it was downloaded.

Design
and imp
lementation
b
ugs have been discovered in the commercial scripting products provided
with many browsers, including those from Microsoft, Apple, Mozilla, and Opera.



AJAX

-

JavaScript is one of the main components of AJAX, a collection of technologies that
allows
Web

dev
elopers to improve the user interaction and response times for rendering
Web

content. AJAX allows
Web

content to behave more like traditional applications, but with
increased complexity, which also increases the attack surface of a
Web

application. Secur
ity
concerns raised about AJAX

can be found at
http://www.cyberwart.com/files/notourtools/AJAXdangers.pdf




Visual Basic Script
-

VBScript is a subset of the widely used Microsoft Vi
sual Basic programming
language and works with Microsoft ActiveX controls. The language is similar to JavaScript and
poses similar risks.



Active X

-

ActiveX is a set of technolog
ies from Microsoft that provide

tools for linking desktop
applications to the
Web
. The ActiveX security model is considerably different fro
m the Java
sandbox model
. The Java model is designed to restrict the permissions of applets to a set of safe
actions based on the source or author of the code via the Java security manager. Ins
tead, ActiveX
controls are digitally signed by their author under a technology scheme called
Authenticode
. The
digital signatures are verified using identity certificates issued by a trusted certificate authority to

an ActiveX software publisher. If the c
ontrol cannot be authenticated by the browser t
he user will
be prompted before an Active X control is downloaded with a warning that the control may not be
safe. Often the user is unaware of the implications of their decisions. Like any other application

that supports mobile code, ActiveX
-
enabled browsers provide a potential vehicle for malicious
code delivery.




Adobe Flash



Browser plug
-
ins such as Flash allow browsers to support new types of content,
they are not active content in and of themselves, b
ut si
mply an active
-
content
-
enabling
technology. Flash
is a broadly
-
deployed
, but its security controls are still in their infancy.
Unfortunately, both web applications using Flash and web applications not using Flash are
affected by insecure design of Ad
obe's Flash Player. More Information about the security of Flash
can be found at
http://code.google.com/p/doctype/wiki/ArticleFlashSecurity

.



Adobe Shockwave

-

Shockwave was design
ed for making a wide variety of online movies and
animations authored in Adobe’s Director Application. Its actual use has become concentrated in
the area of game development. It is often used in online applications which require a very rich
graphical envir
onment. There

is

numerous security vulnerabilities associated

with this player.


Information Security Guideline


More information on Shockwave security can be found at
http://kb2.adobe.com/cps/319/tn_3199.html




In theory, confi
ning a scripting language to the boundaries of a
Web

browser should provide a relatively
secure environment. In practice, this has not been the case. Many browser
-
based attacks stem from the use
of a scripting language in combination with
a
security vulner
ability. The main sources of problems have
been twofold: the prevalence of implementation flaws in the execution environment and the close binding
of the browser to related functionality such as an email client
.
The increasing use of client scripting
tech
nologies at
Web

sites has opened new avenues for exploits

that administrators and developers should
be aware of
.



Content Generation

Content generators are programs on a
Web

server that dynamically generate HTML pages for users; these
pages may be generat
ed using information retrieved from a backend server, such as a database or directory,
or possibly user
-
supplied input. The danger with content generators occurs when they blindly accept input
from users and apply it to actions taken on the
Web

server. If

the

content generator has not been
implemented correctly to restrict input, an attacker can enter certain types of information that may
negatively affect the
Web

server or compromise its security.
Also, a compromised
Web

server may
eventually be used to
deliver malicious active content

(as mentioned above)
to
Web

browsers visiting the
site.


A variety of active content generation technologies exist. These include:




CGI scripts



A CGI application runs as a separate process and is capable of accessing oth
er hosts
or resources to perform it
s

function subject to its system security permissions. These scripts
consume a significant amount of computational resources thus the other programming interfaces
mentioned
below offer better performance. There are t
ool
s such as Whisker (Rain Forrest Puppy)
or wCGIchk
that
can be used to

ascertain vulnerabilities

in these scripts
.
They should be used to
d
etermine
the
vulnerabilities
and

whether there is a process
/patch

to fix the
m.



Server Side Includes (SSI)



SSI comma
nds are embedded within HTML comments (e.g., <!
--
#include file="standard.html"
--
>). As the server reads the template file, it searches for HTML
comments containing embedded SSI commands. When it finds one, the server replaces that part of
the original HTM
L text
with the output of the command.
A subset of the directives available
allows the server to execute arbitrary system commands and CGI scripts, which may produce
unwanted results. SSI is susceptible to command injection attacks, which involve an attac
ker
providing malicious code that is processed and executed by the
Web

server. This allows the
attacker to run arbitrary system commands using the privileges of the
Web

server.



Sun’s Java Server Pages, i.e. JSP



Microsoft

Active Server Pages, i.e.
ASP.NET

(Recommended)

-

An ASP page is essentially a
template that contains server
-
side scripts which are executed when a browser requests a
.asp
resource from the
Web

server.
As with Java, code written in .NET can be downloaded and run
from untrusted sources. T
o alleviate this problem, Microsoft has integrated code access security
into the .NET Framework. Code access security provides various levels of trust for code based on
where the code originates and allows individual users to specify what permissions will
be given to
an application. Because code access security is part of the .NET Framework, all applications that
access the .NET Framework can be subject to code access security. Because policies are defined
on a per machine basis, libraries are provided that

allow applications to determine whether the
application has a particular permission before performing a potentially restricted act

allowing
.NET applications to alter their behavior rather than simply

generate a security exception.
Neverthe
less, like Jav
a, implementation
bugs have been found in .NET that may allow attackers to
bypass security mechanisms. (
http://www.microsoft.com/technet/security/bulletin/ms07
-
jun.mspx
)



Jave

Enterprise Edition, i.e.
JAVA EE

(Recommended)

-

Java Enterprise Edition (EE) is based on
Java technology and provides a comprehensive means to develop applications on the server based

Information Security Guideline


largely on modular components. A type of server
-
side applet called a s
ervlet is used to provide
dynamic
content.
The Java EE server typically populates itself with the servlet objects that

remain
inactive until invoked.
Servlets allow developers to take advantage of an object
-
oriented
environment on the
Web

server, which i
s flexible and extendible. Moreover, untrusted servlet
objects can be executed in a secure area via the Java security manager, with the dynamically
generated information being passed from the secure area into the remaining server environment.



PHP Hypertex
t Preprocessor (
PHP
)
-

PHP is commonly used to extract data from a database and
present it on a
Web

page and provides a number of options that

simplify development. I
t is a rich,
powerful scripting environment with subtle processing implications, and some
options can make it
more difficult for novices to develop secure programs.
Older versions have known vulnerabilities

but

it is
perhaps the most common
Web

application language and framework in use today.

Use or

Upgrade to PHP 5.2 as it eliminates many lat
ent PHP security issues and allows for safer APIs
)
.


The benefits of each of these active content technologies must be carefully weighed against the risks they
pose.
When employing active content technology, security measures should be put in place to red
uce risk
to an acceptable level and to recover if an incident occurs.

One should be aware of the security
merit/demerits of the partic
ular content scheme
in use.
M
ore information
can be found in NIST SP800
-
28
Guidelines

on Active Content and Mobile Code

as well as the other references listed below.


Securing the
Web

Application


Web

Applications present developers and designer with many challenges. Of the threats described above
the majority

of them are realized because

the
Web

Application itself has

fai
led to protect against them.

There are many excellent resources available that describe in detail how to
securely

build
Web

Applications.
The Open
Web

A
pplication Security Project (OWASP) has developed a guide containing
Web

application development best
practices on their site at

http://www.owasp.org/index.php/OWASP_Guide_Project
.

It is strongly

recommended that if you are
developing
Web

based applic
ations you review this document as well

as the others refere
nced

below.


So
me of the Top Issues to

be addressed with the secure desi
gn of a
Web

application are

mentioned

below.

This is not an exhaustive list. The developer/designer should seek additional resources to get the necessary
knowled
ge and skill set to code
securely
.


Web

Application Design Issues


Information Security Guideline






Failure to address these issues manifests itself in three general areas where server applications can
introduce security vulnerabilities at the server:




By

intentionally or unintentio
nally leak
ing

information about the host system that can aid an
attacker, for example, by allowing access to information outside the areas designated for
Web

use.



When processing user
-
provided input, such as the contents of a form, URL parameters, or a se
arch
query, they may be able to be tricked into executing arbitrary commands supplied in the input
stream.



When returning user
-
provided content, such as an email or uploaded video, they may deliver
malicious content constructed by attackers for execution
in other users’
Web

browsers.


An in
-
depth discussion on this matter can be found in NIST SP 800
-
44 Version 2,
Guidelines on Securing
Public
Web

Servers
.

Web

sites that provide active content should perform additional steps to protect the
active content
an
d application
fr
om compromise
.

Also
developers/designers should be aware of the basic
controls available to secure
Web

applications.
These
considerations should be taken into account:





Because of the prevalence of PHP applications c
onsider

the following

details

when using PHP
:


o

register_globals (should be off, will break insecure apps)

o

allow_url_fopen (should be off, will break apps that rely on this feature, but protect
against a very active exploit vector)

o

magic_quotes_gpc (should be off, will break

older insecure apps)

o

open_basedir (should be enabled and correctly configured)

o

Consider using least privilege execution features like PHPsuexec or suPHP

o

Consider using Suhosin to control the execution environment of PHP scripts

o

Use Intrusion Preventio
n/Detection Systems to block/alert on malicious HTTP requests.
Consider using Apache's mod_security to block known PHP attacks


Information Security Guideline


o

As a last resort, consider banning applications which have a track record of active
exploitation, and slow response times to fix

known security issues.

o

Consider using PhpSecInfo
http://phpsec.org/projects/phpsecinfo/index.html


PhpSecInfo

provides a

function that reports security information about the PHP
environment,

and offers suggestions for improvement. It can be a useful tool in a
multilayered security approach.




Beware of t
hird party scripts for
Web

servers that can be downloaded from the internet.

There are
many examples of malicious code being distributed this

way. In general, no third
-
party scripts
should be installed on a
Web

server unless they are first subjected to a thorough code review by a
trusted expert.



For
Web

applications

that handle
Protected
/Confidential

I
nformation and/or

are restricted by
usernam
e and password, none of the
Web

pages in the application should be accessible without

executing the appropriate authentication

process.



The executable code’s ability to read and write programs should be limited. Code that reads files
may inadvertently vio
late access restrictions or pass sensitive system information. Code that writes
files may modify or damage documents or introduce Trojan horses.



Code that is privileged should be as short as possible to facilitate analysis by a skilled person.
If
possibl
e do not use tainted variables within privileged code if used for public services.

For
programming languages that support Tainted Checking turn on Tainted mode.



The code’s interaction with other programs or applications should be analyzed
if possible
to
i
dentify security vulnerabilities. For example, many CGI scripts send e
-
mails in response to form
input by op
ening up a connection with the S
endmail program. Ensure this interaction is performed
in a secure manner.



The code should use explicit path names w
hen invoking external programs. Relying on the PATH
environment variable to resolve partial path names is not recommended.



Assume all input is Malicious.
The developer should

fully consid
er

the implications of incoming

data in terms of the URL, method, c
ookie, HTTP Headers and data fields.

Proper input validation
is one of your strongest measures of defense against today’s application atta
cks
an
d an

effective
countermeasure that can help prevent XSS, SQL injection, buffer overflows, and other input
attac
ks.



o

For data entry forms, determine a list of expected characters and filter out unexpected
characters from input data entered by a user before processing a form. For example, on
most forms, expected data falls in these categories: letters a
-
z, A
-
Z, and

0
-
9. Care should
be taken when accepting special characters such as &, ′, ″, @, and !. These symbols may
have special meanings within the content generation language or other components of the
Web

application.

o

Beware of canonicalization
issues. You shoul
d generally try to avoid designing
applications that accept input file names from the user to avoid canonicalization issues.

Microsoft has an HTTP
module that implement
s

canonicalization best practices as part of
their ASP.NET architecture
.

You can find
more information on this here
http://support.microsoft.com/default.aspx?scid=kb;EN
-
US;887459


o

A
Web

site may inadvertently include malicious HTML tags or script in a dynamically

generated page based on unvalidated input from untrustworthy sources. This can be a
problem when a
Web

server does not adequately ensure that generated pages are properly
encoded to prevent unintended execution of scripts, and when input is not validated
to
prevent malicious HTML from being presented to the user.

See CERT Advisory CA
-
2000
-
02 “Malicious HTML Tags Embedded in Client
Web

Requests”,

http://www.cert.org/advisories/CA
-
2000
-
02.ht ml

.

Ensure that there is a process whereby
dynamically generated pages do not contain undesired tags
.

o

Do not trust HTTP header information. It is easy for an attacker to manipulate the header
to obtain information. Validate this information to guard agains
t information disclosure
threats.


Information Security Guideline





Do not rely on Client
-
Side v
alidation. The client may be compromised and thus have these client
-
side routines disabled.

Ensure that the application does not rely on the client keeping information
such

as
h
idden form fiel
ds and
p
arameters
.

Ensure that any information, which is capable of being
changed by the client, is stored on the server side.



To mitigate client side attacks e
nsure that

the dynamically generated content

do
es

not conta
in
dangerous metacharacters. Certain

threats allow the
attacker
to place these tags in a database or a
file. When a dynamic page is generated using the altered data, the malicious code embedded in the
tags may be passed to the client browser. Then the user’s browser can be tricked into runni
ng a
program of the attacker’s choice. This program will execute in the browser’s security context for
communicating with the legitimate
Web

server, not the browser’s sec
urity context for
communicating
with the attacker. Thus, the program will execute in a
n inappropriate security
context with inappropriate privileges.



Character set encoding should be explicitly set in each page. Then the user data should

and can

be
scanned for byte sequences that represent special characters

for the given encoding scheme.

(See
SIL Internationals “Implementing Writing Systems: An Introduction” for a brief description of
encoding languages at

http://scripts.sil.org/cms/scripts/page.php?s
ite_id=nrsi&id=IWS
-
Chapter03
).

Each character in a specified character set can be encoded using its numeric value.
Encoding the output can be used as an alternate for filtering the data. Encoding becomes especially
important when special characters, such
as copyright symbols, can be part of the dynamic content.
However, encoding data can be resource intensive, and a balance must be struck between encoding
and other methods for filtering the data.



Cookies
used by the
Web

application
should be examined for
any special cha
racters and

be
filtered out.
Protect authentication cookies

using encryption and secure communication channels

such as SSL
.



HTTP cookies in essence add state to the stateless HTTP protocol and are the respon
sibility of the
Web

application.
C
ookies should never contain data that can be used directly by an attacker (e.g.,
username, password). Avoid the use of cookies on public
Web

sites unless there is a compelling
need to gather the data on the site/user.



Another option is to add the httpO
nly Flag to sensitive cookies. When a cookie is set and tagged
with httpOnly, JavaScript is then unable to read the cookie value. Meaning, when a Cross
-
Site
Scripting attack occurs, the hacker gets an empty value from the cookie and stealing it becomes a
p
ointless exercise, thereby making a session hi
-
jacking attack via Cross
-
Site Scripting much
harder. This feature is only supported in Internet Explorer.

You can find more information on this
attribute at
http://www.owasp.org/index.php/HTTPOnly

.


For
Web

sites that need to maintain session information, the sess
ion identifier can be passed as
part of the URL to the
Web

site rather than stored as a cookie.


Consider how

session state is to be
stored.
For optimum performance, you can store

session state in the
Web

application’s process
address space. However, this approach

has limited scalability and implications in
Web

farm
scenarios, where requests from

the same user cannot be guaranteed to be handled

by the same
server. In this

scenario, an out
-
of
-
process state store on a dedicated state server or a persistent state
store in
shared database is required. ASP.NET supports all three options.


If a
uthentication

and session

cookies must be used then protec
t them. A stolen Authentication
cookie is a stolen logon. Protect them by using an SSL session. Also limit the time interval in
which the cookie remains valid.

A good reference on this topic is

“Dos and Don’ts of Client
Authentication on the
Web
”, Kevi
n Fu, Emil

Sit, Kendra Smith, Nick Feamster
-

MIT Laboratory
for Computer

Science

http://cookies.lcs.mit.edu/pubs/
Web
auth:tr.pdf



An encryption mechanism

such as SSL

should be used to encrypt p
asswords entered through
script forms
.



Information Security Guideline




In all cases
programmers/developers should maintain a level of security expertise that includes up
-
to
-
date knowledge of
Web

application security and techniques for secure
Web

programming. This
is especially importan
t if the Web Site will be handling protected and/or confidential information.

It is highly recommended that they demonstrate their skill and knowledge of secure
Web

application programming by achieving the appropriate certification. The certification

sho
uld

be
kept current, which is critically important due to the changing nature of
Web

technology and
security threats
.



Ensure you have a process where you are keeping abreast of new vulnerabilities by subscribing to
mailing lists like CERT.


Securing Comm
unications


Use SSL/TLS to prevent attackers from retrieving information from the HTTP messages sent over the
network and using it to hijack a user’s session.

If the content contains protected information the session
must be authenticated and encrypted.
SSL/TLS can encrypt most of the information being transmitted
between a
Web

browser (client) and a
Web

server or even between two
Web

servers. With an appropriate
encryption algorithm, SSL/TLS provides a high degree of confidentiality. In addition, all dat
a sent over an
encrypted SSL/TLS connection is protected with a mechanism for detecting tampering; that is, for
automatically determining if the data has been altered in transit

thus protecting the Integrity of the data
.


Additional points to consider:




A
void self signed certificates on Public
Web

server.
Some organizations decide to create and sign
their own
Web

server certificates instead of having certific
ates issued by third
-
party CAs.
Web

browsers will not be able to validate self
-
signed certificate
s, so they provide no assurance of the
legitimacy of the certificate or the
Web

server. Given the increasing use of phishing and other
techniques to trick users into visiting rogue
Web

sites, failing to authenticate the server’s identity
before using SSL/T
LS with it is unacceptable
.
All administrators should be aware of the inherent
weakness of PKI and the certificate system. An excellent article on this
April 2009, Online Trusts
and Other Broken Things”
can be found at the Computer Security Insti
t
ute’s
W
eb
site
www.gocsi.com

.



If a particular
Web

server is only going to be accessed from internal

systems then those systems’
browsers could be provisi
oned with the root certificates
needed to validate the
Web

server’s sel
f
-
signed certificate and authenticate the server’s identity.

If this is not feasible the users should be
instructed to ignore the warning to the user that says the
Web

server’s certificate could not be
verified and simply proceed.



Consider the strength of

the SSL/TLS Cipher Suite you use.



Information Security Guideline







Disable SSL 1.0 and SSL 2.0. These protocols have been
replaced

by SSL 3.0 and TLS 1.0. For
IIS
, Microsoft has an

article on how to do that here
http://support.
microsoft.com/kb/187498

.




Do not use the MD5 hash algorithm. MD5 collisions attacks are now conceivable
.


Other Considerations




Ensure
the system is adequately documented. The documentation should include:


o

Server and A
pplication settings

o

Content gen
eration mechanisms, algorithms and modules

o

R
esource permissions

to include users and processes

o

If protected information is used, w
hat it is, where it is stored
, how access is provided

o

Who is responsible for managing the
Web

applications and who owns the d
ata

o

A process to manage operations and

changes




Use a secure network infrastructure to place the
Web

server in.
The network infrastructure is the
first line of defense between the Internet and a public
Web

server. Network design alone, however,
cannot pro
tect a
Web

server. The frequency, sophistication, and variety of attacks perpetrated
today lend support to the idea that
Web

security must be implemented through layered and diverse
protection mechanisms (defense
-
in
-
depth).

See the
03.02.04
Firewall Guidel
ine for recommended
architectures.



U
se an HTTP filter/
application layer
firewall hardware or software as an additional layer of
protection. Many administrators often put this service behind Microsoft’s ISA Firewall which has
a very good filtering capabili
ty.
The network perimeter has been design to accommodate these
application layer firewalls. See 03.02.05 DMZ Guidelines for more information.
Threat Sentry is
also another good product that is software based. More information can be found at
http://www.privacyware.com/intrusion_prevention_2.html

.



Suppressing
error m
essages back to the connecting browser can reduce the ability to
reverse
engineer the system and backend architecture
.
For example, o
nce an attacker
understands

the
applications in use and

their versions
,

they
can target the associated vulnerabilities. By
suppressing certain error messages that allow the attacker to profile the system the difficulty for
successful
Comma
nd

Execution category
attacks increases. The

goal is to in
crease the difficultly
of attacker to

reverse engineering the backend system. Without access to inform
ative error

Information Security Guideline


messages, the attacker

is forced to perform the attack while blind to the system in
ternals. This
defense makes these classes of vulnerabilities many times harder for a hacker to detect and further
exploit.



Send detailed e
rror messages to the error log.
Make sure that you do not log passwords or other
sensitive data.

Ensure that the inf
ormation provided by the logs is useful and provides sufficient
detail.



Audit and log

access across the tiers of the

application for non
-
repudiation. Use a

combination of
application
-
level logging and platform auditing features, such as

Windows, IIS, and S
QL Server
auditing.


The types of events that should be logged incl
ude
:


o

S
uccessful and failed logon
attempts,

o

M
odification of data,

o

R
etrieval of da
ta,

o

Network communications


o

A
dministrative functions such as the e
nabling or disabling of logging



Logs
should

i
nclude the time of the event, the location of the event including the machine name,

the identity of the current user, the identity of the proc
ess initiating the event, and a
detailed
description of the event.


Secure log files using the operating s
ystems

ACLs and restrict access
to the log files. This makes
it more difficult
for attackers to tamper with log files to c
over their tracks. Minimize the
number of
individuals who can manipulate the log
files. Authorize access only to
highly trusted accoun
ts
such as administrators.


For

Public

Web

Services

and/or those
that use
Protected Information consider

sending the log
s

to
INFOSEC
’s

Monitoring, Analysis, Response System

(MARS)
.



Use IIS Lockdown, URL Scan, Mod_S
ecurity, and SecureIIS

to help you secure

and test

your
Web

Server.
Below is a list of products that can help you do that
. This list is not inclusive;

there
are other great products out
there to help you
.


IIS Lockdown

http://www.microsoft.com/windows2000/en/server/iis/default.asp?url=/windows2000/en/server/iis
/htm/core/iierrabt.htm


IIS Lockdown, designed for Microsoft's Internet Information Server (IIS), assists b
y allowing
administrators the ability to easily turn off unnecessary features that might pose a security risk.
With IIS Lockdown you can disable unnecessary services, un
-
map unused file handlers, un
-
map
unused sample scripts and directories, modify permiss
ions, etc. And making configuration a
breeze, a GUI
-
Driven interface and security templa
tes are made available as well.

URL Scan

http://www.microsoft.com/technet/security/tools/url
scan.mspx


URL Scan, again designed for IIS, picks up where IIS Lockdown leaves off by focusing on the
http request specifically. Attacks on
Web
sites are usually achieved by using specially crafted
URL's. These URL's may contain special characters, be ov
erly long, or even cleverly encoded to
disguise an attack. URL Scan helps by using rules to interrogate several facets of an http request.
If anything looks out of the ordinary, an exception can be raised.


If you're already using IIS 6.0, Microsoft recom
mends you evaluate the need to use URL Scan at
all. Most of the important functionality of URL Scan is already included in the
Web

server.


IIS Lockdown and Urlscan


Information Security Guideline


http://www.securityfocus.com/infoc
us/1755

Mod_Security

http://www.modsecurity.org/


Mod_Security is the Apache equivalent of URL Scan. By working in conjunction with Snort rules,
Mod_Security can be used to analyze the legitimacy of an incoming
http request. Simple rules can
be configured to stop many forms of SQL Injection, Cross
-
Site Scripting and a host of other
undesirables


Introducing mod_security

http://www.onla
mp.com/pub/a/apache/2003/11/26/mod_security.html


Web

Security Appliance With Apache and mod_security

http://www.securityfocus.com/infocus/1739

SecureIIS

http://www.eeye.com/html/products/secureiis/


A commercial

product by Eeye, SecureIIS is

specifically designed as an IIS ISAPI filter to block
incoming attacks. Using specially crafted filter rules (no signatures to update), SecureIIS sit
s
between the Internet and the
Web

server to protect against buffer overflows, parser evasions,
directory traversal and other attacks. Another good add
-
on to have.


Others include
tools like
Web
Scarab
,
Firefox's
Web

Developer Toolbar
,
Greasemonkey

and the
XS
S Assistant


Vulnerability Assessments


To determine if you are at risk
Web

scanning tools can

be used to help find

vulne
rabilities, particularly if
there

are known bugs. However, to find all potential vulnerabilities requires a source code review as well

as
an application penetration test. These should be done by the developers

or INFOSEC
prior to release of any
important
Web

application.


System administrators should consider scanning
Web

servers periodically with vulnerability scanners,
particularly if
they run a large or diverse range of user
-
supplied scripts (such as on a hosting farm).


INFOSEC will scan and audit
Web

servers periodically
for

network and application
vulnerabilities.
(Network security scanners may detect vulnerabilities in the
Web

ser
ver, OS, or other serv
ices running on
the
Web

server.
Web

application vulnerability scanners specifically scan for co
ntent generator
vulnerabilities
).

Scanning will be done in such a manner that the systems will not be interrupted and only
upon notifying
the Administrator and Business Unit. If a scan has the potential for disrupting systems, the
system administrator will be involved in scheduling the scan.
Should a vulnerability or security risk that
threatens the network be found
,

the Administrator will
be notified.
The InfoSec Team will work with the
administrator if necessary to remove the vulnerability from the system. If the vulnerability has not been
mitigated within a determined period of time the InfoSec Team reserves the right to remove the syst
em
from the network until the vulnerability has been mitigated.


References


“Guidelines o
n Securing Public
Web

Servers”
NIST SP800
-
44

http://csrc.nist.gov/publications/PubsSPs.html



“Guidelin
es on Active Content and Mobile Code” NIST SP800
-
28 version2

http://csrc.nist.gov/publications/PubsSPs.html




Information Security Guideline



03.03.01 Windows Server (2003) Hardening Guideline

http://s
ecpriv.wusm.wustl.edu/infosec/Information%20Security%20Policies/Forms/AllItems.aspx?RootFol
der=%2finfosec%2fInformation%20Security%20Policies%2f3%20Technical%20Policies%20and%20Guid
elines&FolderCTID=&View=%7bBF3E879F%2d52C0%2d4DBD%2dB9A2%2d64806DB760A3%7d


03.03.02 Unix/Linux Server Hardening Guideline

(Document Forthcoming)


CIS_IIS_Benchmark_v1.0.pdf and Apache CIS_Apache_Benchmark_v2.2.pdf at
http://www.cisecurity.org/benchmarks.html



Web

Appli
cation Security Consortium: Threat Classification

http://www.
Web
appsec.org/projects/threat/



Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication

http://msdn.microsoft.com/en
-
us/library/aa302415.aspx




A Guide to Building Secure
Web

Applications and
Web

Services

http://www.
owasp.org/index.php/OWASP_Guide_Project



“Improving
Web

Application Security: Threats and Countermeasures

June 2003”

http://msdn.microsoft.com/en
-
us/library/aa302432.aspx




“Dos and

Don’ts of Client Authentication on the
Web
”, Kevin Fu, Emil

Sit, Kendra Smith, Nick Feamster
-

MIT Laboratory for Computer

Science

http://cookies.lcs.mit.edu/pubs/
Web
auth:tr.pdf


03.02.04 Fir
ewall Guideline

http://secpriv.wusm.wustl.edu/infosec/Information%20Security%20Policies/Forms/AllItems.aspx?RootFol
der=%2finfosec%2fInformation%20Security%20Policies%2f3%20Technical%20Policies%20and%20Guid
elines&FolderCTID=&View=%7bB
F3E879F%2d52C0%2d4DBD%2dB9A2%2d64806DB760A3%7d



03.02.05 DMZ Guidelines

http://secpriv.wusm.wustl.edu/infosec/Information%20Security%20Policies/Forms/AllItems.aspx?RootFol
der=%2finfosec%2fInformation%20Security%20Policies%2f3%20Tec
hnical%20Policies%20and%20Guid
elines&FolderCTID=&View=%7bBF3E879F%2d52C0%2d4DBD%2dB9A2%2d64806DB760A3%7d



Information Security
Contact Information


INFOSEC@wusm.wustl.edu