Transcript Session 2 new

Session 2 Objectives

Learn the basic concepts of web infrastructure and
associated terminology.

Understand the risks that impact web infrastructure and
the controls to mitigate them.

Gain the skills to assess the security posture of a web
infrastructure and make management
recommendations.

Apply security principles and best practices to a web
infrastructure.
1
The Big Picture
Elements of the web
infrastructure.
Some risks that impact
the infrastructure.
2
Web primer
Web: Series of computers connected to each other via a
network (Internet) and use common set of languages.

Broadly speaking, web essentially is a series of clients
(browsers) and servers (web servers) that talk to each
other via an agreed upon protocol (http), display results
in a common format (HTML) over a shared network
(Internet).

The web client is essentially an application software,
commonly known as a browser. Examples of browsers
include Microsoft’s Internet Explorer, Mozilla’s Firefox,
Apple’s Safari, etc.
3
Web primer
Web: Series of computers connected to each other via a
network (Internet) and use common set of languages.
Web clients perform the following key tasks:



Send requests to web servers

Use http or SSL to send requests

Receive response and render it on screen

Run mobile code (ActiveX, Java applets) sent by the server
In addition, web browsers can support other protocols
like ftp to transfer files. Some of the newer browsers
support transfer technologies like BitTorrent too.
4
Web primer
Web: Series of computers connected to each other via a
network (Internet) and use common set of languages.
Web servers receive the requests from the web
browsers and respond via one of the following means:



Send a static page back to the browser

Forward the request to a web application to compose a
response

Send mobile code to the browser to execute
Responses from web servers are typically in HTML
format. Over the last few years, responses in XML
format have become popular which are rendered by the
browser for display. Also, for mini-browsers, the
responses maybe in WML format.
5
Web primer
Web: Series of computers connected to each other via a
network (Internet) and use common set of languages.

Common web servers include open-source Apache,
Microsoft’s IIS, etc.

Applications servers often receive the request from web
servers and host the business logic to build a response.


They host the web applications

Communicate with the backend databases via ODBC/JDBC

Provide a robust support environment for the applications
(clustering, redundancy, security, etc.)
Common application servers include IBM’s WebSphere,
BEA’s WebLogic, etc.
6
Web primer
Web: Series of computers connected to each other via a
network (Internet) and use common set of languages.

Web browsers, web servers, application servers, and
databases are key components of a web infrastructure.
7
Management concerns
Concerns about operating system security typically include
the following:

Maximizing the availability and performance company’s
web sites to protect revenue and image.

Maintaining the integrity and confidentiality of employee
and customer data passing through web applications.

Alleviating privacy concerns for employees and
customers.

Keeping up with existing and upcoming security threats
and implementing mitigating controls.

Having an effective backup, recovery, business
resumption and a disaster recovery plan.
8
Risks and controls
Web browsers: Client applications used by end users to
request and receive responses from websites.

Web browsers are user’s front-end into web applications.

Web browsers have become another target for malicious
users to attack others. Some of the risks associated with
web browsers include:

Privacy concerns for end users

Attacks on session management

Risk of mobile code

Insecure security zones

Phishing scams
9
Risks and controls
Privacy: Web browsers can lead to privacy concerns for end
users.

Web browsers have features that improve browsing
experience and convenience for web users. However,
these can cause privacy concerns.

The “autocomplete” feature in some browsers like Internet
Explorer remembers entries made by users on web
pages, search engines, text boxes.

“History” feature within browsers maintains a history of
websites visited by the user. Some even maintain a log
of files transferred over the web.
10
Risks and controls
Privacy: Web browsers can lead to privacy concerns for end
users.

Many browsers remember a feature to remember userIDs
and passwords for logging onto various websites.

Most browsers maintain a cache that contain local copies
of web pages visited by users.
11
Risks and controls
Privacy risks:

Anyone with physical access to the machine can gain a
fairly detailed view of activities of the previous user.
Controls:

Disable autocomplete, history, cache features – however,
this comes at a loss of functionality.

Newer browsers come with “clean-up private data” upon
exiting option which helps maintain privacy.
12
Risks and controls
Session management: Web browsers have to maintain
sessions with websites.

HTTP is stateless protocol – every transaction between
the browser and the server is independent of each
other. Subsequent transactions don’t know anything
about previous transactions (state is not maintained).

This poses problems for applications that need state
information to manage a session.


For example, it may authenticate a user in a transaction, and
would need to remember the user is authenticated for
subsequent transactions until the user logs out.
Web developers achieve session management via a
couple of means: cookies and session IDs.
13
Risks and controls
Session management: Cookies help maintain state.

Cookies are small data files that are given to a browser
by a web application when a user first visits.

Every subsequent visit, the application checks if a
cookie exists (and if so, its contents) and thus knows if
a user has previously accessed the application and
what was done in the previous transaction.

Cookies can be persistent (written to hard drive) or nonpersistent (in browser memory).

Cookies can have expiration dates.
14
Risks and controls
Session management: Cookies help maintain state.

Cookies can be secure (encrypted in transmission) or
non-secure (not encrypted).
15
Risks and controls
Session management: Session IDs help maintain state.

Session IDs are token numbers given to a client by a
web application when a user first visits.

The session data associated with the user is stored on
the server side (as opposed to cookies which are stored
on client) and can be referenced via the session ID.

Every subsequent visit, the client provides the session
ID to the application which checks the session store and
thus knows if a user has previously accessed the
application and what was done in the previous
transaction.
16
Risks and controls
Session management: Session IDs help maintain state.

Session IDs can be passed via the URLs or via hidden
fields in the forms submitted.
17
Risks and controls
Session management risks:

Cookies can manipulated by end users to elevate
privileges or impersonate others.

Cookies can be sniffed/stolen leading to impersonation.

Session IDs maybe predictable allowing attackers to
impersonate other users.

Session IDs may be sniffed.
Controls:

Encrypt the contents of the cookies to prevent
manipulation.
18
Risks and controls
Controls contd.:

Encrypt the contents of the cookies to prevent
manipulation.

Implement checksums on cookies and/or session IDs to
ensure they haven’t been tampered with.

Avoid storing authentication credentials in cookies.
Server side storage of data is more secure.

Session IDs should be random preventing its prediction.

Use SSL or other encryption methods to prevent
sniffing.
19
Risks and controls
Mobile code: Code sent by a website to a browser for
execution.

The functionality offered to users is greatly enhanced by
mobile code sent by browsers. Else, a browsers would
be able to mostly display static content only.

Besides scripting languages like JavaScript, web
servers send executable code to browsers via two key
technologies: Java applets and ActiveX.

Java applets are Sun’s technology whereas ActiveX is
Microsoft technology. Both work conceptually similar, in
that upon visiting a website, the code is sent to be
loaded and executed by the browser.
20
Risks and controls
Mobile code: Code sent by a website to a browser for
execution.

However, Java applets and ActiveX have fundamentally
security models.

Java applets use a “sandbox” model, wherein the code
is restricted in terms the system resources it can access
and system commands it can invoke. This prevents the
code from doing any damage to the system.

ActiveX follows an “Authenticode” model, wherein the
code can perform any action without any limitations,
however, the code has to be digitally signed by the
author thereby assigning accountability.
21
Risks and controls
Mobile code risks:

Flaws have been identified that let Java applets to
breach the “sandbox”.

End user is assigned the responsibility of determining
whether to trust the signed ActiveX code.

Many unsafe ActiveX controls (programs, from various
vendors) are marked “safe-for-scripting” (which allows
them to be invoked by any malicious web page/e-mail).
Controls:

Disable mobile code to the extent possible.
22
Risks and controls
Controls:

Disable unsigned ActiveX and consider the same for
signed ActiveX.

Allow mobile code to be executed only in from trusted
websites.
23
Risks and controls
Security zones: Browsers allow users to classify websites
by their trust factor.

End users can have granular definitions of trust via
security zones.

Typical zones include the following (in the order of
increasing trust / decreasing restrictions)


Restricted sites

Internet sites

Local intranet sites

Trusted sites
Every zone can be further customized to specify who
can run mobile code, who can download mobile code,
whether to run code with / without prompting, etc.
24
Risks and controls
Security zone risks:

Default zones (“Internet”) often aren’t tightly secured.
For example, it allows ActiveX controls, Java, unsigned
.NET components etc.
Controls:

Review each configuration feature available in a zone
and decide whether it should be allowed or not.

Follow the recommended “deny if not allowed”
approach rather than the “allow if not denied” approach.
25
Risks and controls
Phishing: Internet-based scams that targets endusers personal/confidential information.

Scammers “ph-ish” (fish) for userIDs,
passwords, bank account numbers, social
security numbers, etc. from unsuspecting end
users via a variety of techniques.

Techniques include sending social engineering
via spoofed e-mails that seem to come from
legitimate sites asking for confidential
information, fake websites that capture userIDs
and passwords etc.
26
Risks and controls
Phishing risks:

These attack lead to fraudulent transactions, identity
theft, disclosure of sensitive information, etc.
Controls:

User education is the key to protection against phishing
attacks.

Effective spam control can protect users against
phishing e-mails that lead them to fake websites.

Newer browsers have features that warn users against
possible phishing websites.
27
Risks and controls
Web servers: Web servers receive requests from browsers
and send back responses to the same.

Web servers are key to a web site’s availability and need
to strongly protected.

Some of the risks/attacks against web servers include:

Insecure operating systems

Flaws with web server software

Flaws with add-on components
28
Risks and controls
Operating system: Web server software resides on operating
systems that have to be secure.

As mentioned in chapter 7, without a secure operating
system nothing residing on it can be considered secure.

Web servers often reside in the DMZ instead of internal
network (to allow outsiders access to websites).

Hence, they are much more exposed to external attacks,
making the need to secure the OS even higher than OS
on machines that are within the network.
29
Risks and controls
Operating system risks:

Chapter 7 covered OS risks in detail. In general, default
accounts, weak file and directory permissions, insecure
services, missing security patches etc. increase the risk
of the OS (and hence web server) compromise.
Controls:

Evaluate the need for each service installed on the OS.
Unnecessary services should be turned off.

Assess the patch deployment process. All necessary
patches should be implemented.
30
Risks and controls
Controls contd:

Review authentication methods, user accounts and their
privileges. Ensure quality user ID and password
management techniques are used.

Determine the legitimacy of trust relationships.

Ensure core OS files are baselined and are protected.

Evaluate the need and security of all file shares.

Determine if additional controls like anti-virus, personal
firewalls, and intrusion prevention systems are in place.

Review all scheduled jobs and their controls.
31
Risks and controls
Web server software: Web server software receives inputs
from browsers and responds to them.

Web server software listens on port 80 for http traffic from
browsers (port 443 for SSL encrypted traffic).

Web server software often works with databases or other
application servers to compose responses to the
browsers.

The configuration of the software can add several risks to
web security.

Web server software often comes with “add-on
components” that add programming and/or administrative
functionality.
32
Risks and controls
Web server software risks:

Web server software runs as a user on the OS. Some
installations define this user with high privileges (out of
choice, ignorance, or necessity). This increases the
fallout associated with a compromise.

Many default installations come with sample scripts and
applications preloaded. These are often exploited by
attackers. For example, IIS had a showcode.asp sample
code that was often used by intruders.

At times web server software provides detailed error
messages that helps attackers footprint the system.
33
Risks and controls
Web server software risks:

Web server software may allow for “directory traversals”
that allows users to navigate outside of directories that
store web pages and read sensitive files.

In addition to web server software, the add-on
components are often susceptible to attacks like buffer
overflows.
Controls:

Keep web server software patched.

Minimize privileges associated with web server software.

Remove all sample scripts, applications etc.
34
Risks and controls
Controls:

Remove sensitive data from source codes.

Install web content on a drive that is separate from the
drive that contains the OS files.

Evaluate the need for each service installed on the OS.
Unnecessary services should be turned off.

Assess the patch deployment process. All necessary
patches should be implemented.

Unused add-on components should be removed or
disabled. The rest should be patched regularly.
35
Risks and controls
Web applications: Web applications reside on web and/or
application servers and provide end users with various
functionality.

Web applications can be compromised via a variety of
ways unless they are programmed really carefully.

Some of the risks/attacks against web applications
include:

Improper input validation

Cross-site scripting attacks

Buffer overflow attacks

SQL injection attacks

Improper error handling
36
Risks and controls
Input validation: Web applications implement controls to
ensure the input entered is valid.

Web applications expect valid input – that is, it is of
correct length, right type (text vs integer), etc.

Developers often insert edit checks via JavaScript that is
executed on the client side.

However end users can always modify these checks
(since they reside on client side) to bypass them and
submit wrong inputs to the application.

At times developers will implement edit checks on the
server side. However, they have to be carefully designed
to avoid being bypassed or to ensure malicious input is
filtered out.
37
Risks and controls
Input validation risks:

Client side input validation should not be relied upon.

Use server side validation checks as far as possible.

Canonicalize the input (decode all input to simplest form)
before processing the input to avoid attacks that use
encoded characters.

Educate developers about various attacks and provide
secure programming training.
38
Risks and controls
Cross-site scripting (XSS) attacks: Code injection by
malicious users into web pages viewed by web users.

Web browsers receive mobile code (say JavaScript) from
web servers all the time.

This (JavaScript) code is executed in the browser and
has access to all objects (cookies, web pages, etc.) from
that web server.

This access isn’t a problem since the (JavaScript) code is
provided by the same web server that provided the
objects too.

What happens if malicious user is able to provide the
JavaScript code to the web server, that gets sent to the
web browser?
39
Risks and controls
Cross-site scripting (XSS) attacks: Code injection by
malicious users into web pages viewed by web users.

If so the browser will execute the malicious JavaScript
code as if belongs to the web server browser and allows
access to all the objects. What can this access do?

It can copy the user’s cookie (for that web site), run local
commands (if the web site is trusted), or subject user to
phishing attacks (steal userID and passwords).
40
Risks and controls
Cross-site scripting (XSS) attacks: Code injection by
malicious users into web pages viewed by web users.
So how is malicious code inserted into web servers? This
occurs via web applications that accept user input without
validation. For example


newsgroups web pages may allow a user to enter postings (which
could contain malicious code) and these postings are fed back to
other users to read, subject them to XSS attack.

Social engineering attempts wherein user is convinced to click on
a malicious URL that leads to an XSS vulnerable website.
41
Risks and controls
Cross-site scripting (XSS) attacks: Code injection by
malicious users into web pages viewed by web users.
Several well known websites have been subject to XSS
attacks/vulnerabilities:


Charles Schwab website

Hotmail website

cbs.com

news.bbc.co.uk

Paypal website
42
Risks and controls
Cross-site scripting (XSS) attack risks:

XSS vulnerable websites can lend its users to a variety of
risks including attackers obtaining their credentials,
access to their financial accounts, disclosure of sensitive
data etc.
Controls:

XSS vulnerabilities are bountiful and need a careful
review of all code to identify them.

Provide training to web application developers in
regarding XSS and secure programming.

Stringent input validation is required by web applications
before accepting any input from users.
43
Risks and controls
Controls contd.:

Malicious characters in user input should be removed or
encoded them (so that the browser doesn’t interpret is as
executable code).

Disable scripting on browser so malicious code doesn’t
execute.

Allow only trusted websites to execute code.
44
Risks and controls
Buffer overflows: Attack wherein malicious input spills into
sensitive portions of memory compromising applications.

Buffer overflows were covered in detail in application
security chapter. Buffers are memory locations allocated
by programmers to store user’s inputs.

Attackers may provide malicious input that runs past the
size of the buffer.

Extra input could spill into sensitive portions of memory
with results ranging from nothing happening, to
application crashing, to a complete compromise.

Web server software are often impacted by buffer
overflows attacks.

E.g. Code Red virus attacked IIS web servers.
45
Risks and controls
Buffer overflows: Attack wherein malicious input spills into
sensitive portions of memory compromising applications.
In addition, web applications that use susceptible thirdparty libraries can also be impacted.


E.g. Microsoft’s GDIPlus library was target of buffer overflows.
46
Risks and controls
Buffer overflow risks:

Impact of buffer overflow ranges from application failing
its execution, to its crash, to running of malicious code
of attacker’s choice resulting in complete compromise.
Controls:

Enforce boundary checks before accepting inputs. Use
compilers that warn of potential overflow conditions.

Educate programmers in safe programming practices.

Use languages like Java (instead of C/C++) that don’t
let input easily run past its buffer allocation.

Apply latest patches for third-party libraries.
47
Risks and controls
SQL injection: Attack wherein malicious SQL commands
are passed into web applications via user inputs.

Web applications with back-end databases are often
susceptible to these attacks.

These applications convert user supplied input into SQL
commands that are processed by the database.

Attackers can craft special input that make the SQL
commands malicious in nature.

The database processes these malicious SQL
commands and end up disclosing sensitive data or
running sensitive database commands.
48
Risks and controls
SQL injection: SQL injection attack example.

Consider, a web application, that allows users to type in
a keyword to search a particular product type by asking:
Product keyword: antique

Say, the resulting SQL executed by the database is:
SELECT product FROM product_table
WHERE product_description like ‘%antique%’;

This query results in showing all products from the
product_table that have the keyword ‘antique’ in it.
49
Risks and controls
SQL injection: SQL injection attack example contd.

Now consider, if the user provides the following special
input:
Product keyword: antique%’; DROP table_w_sensitive_data;--

The resulting SQL executed by the database then is:
SELECT product FROM product_table
WHERE product_description like ‘% antique%’;
DROP table_w_sensitive_data; --%’;

This results in display user IDs and password hashes
and deletion of a table!!
50
Risks and controls
SQL injection risks:
SQL injection can lead to web application malfunction,
user impersonation, loss of sensitive data, etc.

Controls:
Do not trust user’s inputs and sanitize user inputs by:


Rejecting known bad data/characters.

Accepting only valid data.

Cleaning bad data.

Don’t use dynamic SQL. Instead use “bind variables” or
“parameterized SQL.”

Minimize privileges of the database application user to
limit the damage if SQL injection succeeds.
51
Risks and controls
Error handling: Web applications return messages back to
the browser when application errors.

Web applications will generate errors due to a variety of
reasons – wrong user input, requests for resources
timing out, invalid database queries, invalid logins, etc.

These errors are meant to either notify the user, or as
debug messages to help diagnose the error condition.

Attackers can gather a wealth of information via these
error messages. This includes structure of databases,
table names, column names, file names, directory
structure, web server version, valid userIDs, etc.
52
Risks and controls
Error handling: Can help attackers gain information. For e.g.
Consider, a web application, that asks users to log in and
user provides the following information:




Consider, the attacker then provides the following:





User = jsmith
Password = something
Application responds “Access denied. Wrong username”.
User = admin
Password = something
Application responds “Access denied. Wrong password”.
This allows attacker a means to identify valid userIDs
(since the error message is different). The more user IDs
the attacker identifies, the better chance of finding one
with a weak password.
53
Risks and controls
Error handling risks:

Information leak via error messages allows attackers to
footprint a web application.
Controls:

Create standard messages for error handling.

Send back error codes that don’t mean anything to
attackers but can help developers to debug errors.

Prevent database error messages from returning back
to users – instead send generic error pages.

Essentially, limit the information that can be gleaned
from error messages.
54
Assurance considerations
An audit to assess web security should include the following:

Ensure the company’s web environment is well-defined
and documented.

Evaluate the fortification efforts for the web server
(operating system security).

Assess the patch deployment process. All necessary
patches should be implemented.

Review the placement of web/application server vis-àvis its business use. Most servers are in the DMZ.
55
Assurance considerations

Evaluate the authentication process for web
applications. Server-side techniques for session
management are preferred.

Ensure the company’s privacy statement addresses the
use of cookies and customer data collected via web.

Determine if browsers used have been patched,
untrusted sites can’t execute mobile code, and zones of
trust have been defined.

Ensure that functional plans for backup and recovery,
business resumption, disaster recovery are in place.
56
Recap
57