Transcript Slide 1

PHP
ASP.NET
JSP
Apache
Perl
Microsoft IIS
Internet Explorer
Hackers
OWASP
Netscape
Agenda
 Understanding
the Web Applications
 OWASP Top 10 Vulnerabilities
 Writing Secure Web Applications
 Auditing Web Applications
 Question and Answers
What is a Web Application?
It is an application that is accessed via a web browser over a network
(Internet or an intranet).
An application, generally comprised of a collection of scripts, that
reside on a Web server and interact with databases or other sources of
dynamic content.
Any Examples?
Some examples of Web Applications include Search Engines,
Webmail, Shopping carts (Amazon, e-bay) and Portal Systems (iGoogle,
Yahoo).
Some examples of Web Applications
What is the key reason for their popularity?

The ability to update and maintain web applications without distributing
and installing software on potentially thousands of client computers.

Require little or no disk space on the client, upgrade automatically with new
features, integrate easily into other server-side web procedures, such as email and searching, does not require any additional hardware or software
configuration for its working.

Its inherent support for cross-platform compatibility.

The web applications include such simple tasks as filling a form for certain
facility (Net Banking to give orders) or working on major projects.

Web applications are easy to use and are more presentable and attractive
than the traditional softwares.
What’s the Business Use?

An emerging strategy for Application Software companies is to provide
web access to software previously distributed as local applications.

These programs allow the user to pay a monthly or yearly fee for use of a
software application without having to install it on a local hard drive.

A company which follows this strategy is known as an application service
provider (ASP), and ASPs are currently receiving much attention in the
software industry.
How the above ones contribute to
Web Applications?
Web Programming Language :

The Web places some specific constraints on our choices: the ability to deal with a
variety of protocols and formats (e.g. graphics) and programming tasks;
performance (speed and size); platform independence; and the basic ability to deal
with other Web tools and languages.

PHP, ASP.NET, JSP (Java Server Pages), Perl and Cold Fusion, which fall into two
main groups – proprietary and open-source.

Above mentioned ones are open-source except the proprietary Cold Fusion and
ASP.NET.
Web Server Software :

Is a computer program that delivers content, such as Web pages, using the
Hypertext Transfer Protocol (HTTP), over the World Wide Web.

Features:
 Virtual hosting to serve many Web sites using one IP address.
 Large file support to be able to serve files whose size is greater than 2
GB on 32 bit OS.
 Bandwidth throttling to limit the speed of responses (not to saturate) and
to be able to serve more clients.
 Server-side scripting to generate dynamic Web pages.

Some examples include – Apache Tomcat, Microsoft IIS etc,.
Web Browser :




A software application for retrieving, presenting, and traversing
information resources on the World Wide Web.
Hyperlinks enable users to easily navigate their browsers to related
resources.
All major web browsers allow the user to open multiple information
resources at the same time, either in different browser windows or in
different tabs of the same window. They include pop-up blockers to
prevent unwanted windows from "popping up" without the user's
consent.
Some popular browsers are – Internet Explorer, Mozilla Firefox,
Netscape Navigator , Safari, Opera etc.,
Open Web Application Security Project
(OWASP)
 OWASP is an open-source application security project.
 OWASP community includes corporations, educational organizations, and
individuals from around the world.
 All of the OWASP tools, documents, forums, and chapters are free and
open to anyone interested in improving application security .
 OWASP is not affiliated with any technology company (free from
commercial pressures), and it provides unbiased, practical, cost-effective
information about application security.
OWASP Top 10 Application Security Risks –
2010
A1 – Injection - Occurs when untrusted data is sent to
an interpreter as part of a command or query.
A2 – Cross Site Scripting (XSS) - Allows attackers to
execute script in the victim’s browser which can hijack
user sessions, deface web sites, or redirect the user to
malicious sites.

A3 – Broken Authentication and Session
Management - occur when developers fail to
protect their users sensitive information such as
user names, passwords, and session tokens .

A4 – Insecure Direct Object References - Occurs
when a developer exposes a reference to an
internal implementation object (file, directory, or
database key).

A5 – Cross Site Request Forgery (CSRF) Forces a logged-on victim’s browser to send a
forged HTTP request, including the victim’s
session cookie and any other authentication
information, to a vulnerable web application.

A6 – Security Misconfiguration - Security
depends on having a secure configuration
defined for the application, framework, web
server, application server, and platform.

A7 - Failure to Restrict URL Access - Many web
applications check URL access rights before
rendering protected links and buttons. Attackers
will be able to forge URLs to access the hidden
pages anyway.

A8 – Unvalidated Redirects and Forwards Web applications frequently redirect and
forward users to other pages and websites, and
use untrusted data to determine the destination
pages.

A9 – Insecure Cryptographic Storage - Many
web application do not properly protect sensitive
data, such as credit cards, SSNs, and
authentication credentials, with appropriate
encryption or hashing.

A10 - Insufficient Transport Layer Protection Applications frequently fail to encrypt network
traffic when it is necessary to protect sensitive
communications.



The threat landscape for Internet applications change with advances by attackers,
new technology, and increasingly complex systems. To keep pace, OWASP updates
the Top 10 periodically.
They have changed OWASP’s ranking methodology to estimate risk, instead of
relying solely on the frequency of the associated weakness.
OWASP Top 10 Risk Rating Methodology





Attack Vector - How hard for an attacker to use this flaw
Weakness Prevalence – How often is it found
Weakness Detectability- How hard is it for an attacker to find the flaw
Technical Impact
This is generic across the internet, not specific to any organization.
Threat
Agent
?
Attack
Vector
Weakness
Prevalence
Weakness
Detectability
Technical
Impact
Easy
Widespread
Easy
Severe
Average
Common
Average
Moderate
Difficult
Uncommon
Difficult
Minor
Business
Impact
?
Cenzic Web Application Security Trends Report Reveals 90% of Web Applications Vulnerable,
Adobe One of the Most Vulnerable.
Source: Cenzic Web Application Security Trends Report
What are the root causes of Application
vulnerabilities?
Every
It
application security problem has a root cause somewhere
in the organization.
may be that the project didn't have the right activities in their
development process, or it may be that the developers didn't have
the right training, or it might even be that the team didn't have the
right tools for the job.
Writing
Secure Web Applications
Sanitize browser input


Two dangers with browser input data

Input containing special characters such as ! and & could cause the
web server to execute an OS command or have other unexpected
behavior.

User input stored on the server could contain malicious HTML tags
and scripts. When another user views the input, that user's web
browser could execute the HTML and scripts.
“The best practice is to strip unwanted characters,
invisible characters and HTML tags from user input”
Don’t put everything in the HTML directory


For example, if your Web Application places a data file named
“card_number.dat” in /public_html, any outsider who guesses the file
name can view its contents in their browser.
“You have separate locations for HTML files, executable programs, shared
library code and data. Separating the data files into sub-directories by
application helps eliminate file naming problems”

Hidden fields aren’t

Many programs rely on so-called "hidden" form fields to store state
information, settings and previous input data.

HTML "hidden" fields are not hidden and not secure. Users can see
them by viewing the HTML source of your form in their browser.
Contents of hidden fields should be sanitized and validated just like any other
user input field. Hidden fields should not be used to set access modes or
privileges for a program.

Use POST instead of GET

HTML forms can be submitted using either GET or POST methods.

The GET method sends all form input to the web application as part
of the URL.
“POST is preferred, especially when sending sensitive information”

Validate on the Server

It's easy for a knowledgeable user to save an HTML form, disable
the embedded Java script, then use the modified form to submit
bad data back to the web application.

When the application expects all input validation to have already
been done by the web browser, and therefore doesn't double
check the input, your Web Application can be compromised .
“Client-side validation should never be trusted as a replacement for
additional server-side validation.”

Avoid real directory or file names
 For example, in a Perl program do NOT do this:
WRONG!> $datafile = param('datafilename');
WRONG!> $open DATAFILE $datafile or die;
 Instead, do something like this:
BETTER> my %filelist = ( "name" => "/home/data/name.txt";
BETTER> "address" => "/home/data/address.txt" );
BETTER> $keyword = param('datafilename');
BETTER> open DATAFILE $filelist($keyword) or die;
“Never use actual directory or file names as parameters or construct
names based on user input. Instead, use keywords that are pointers
and store the actual file or directory names in a lookup table”.

Specify the OPEN mode when opening a file


When opening a file for reading only specify that it should
be opened read-only.
Most programming languages allow modes to be specified
when opening files: read-only, write, append, read/write etc
“Always explicitly specify the mode, especially if a file should only be
opened read-only. Do not rely on the default mode of the programming
language… the default may change in future versions”

Log suspicious errors
 Web applications are frequently attacked by crackers. It's a
good idea to not only trap and recover from errors, but also to
log events that may indicate an attack.
“All applications should be written to trap errors.”
Auditing Web Applications
Verify all INPUT is validated prior to use by Web Server


Discuss with Web Admin the methodology used for input validation for the
Application.
Use filtering criteria such as data type, allowed character set, min & max
length, whether null is allowed, whether parameter allowed or not, numeric
range, special legal values, specific patterns (expressions) etc.,
Verify proper Authorization Controls are enforced


Failure to have a Policy or written Doc for a home-grown application is a
red flag that suggests that access controls are not being enforced correctly.
Typical methods for bypassing given authorization include – Cached Ids; File
permissions; Client Side Caching (PII).
Broken Authentication and Session Management





Account credentials and session tokens must be protected.
Discuss with Admin the authentication mechanism used to authenticate
users to the Web Application.
Web Application should have a built-in facility to handle the life cycle
of user accounts.
Verify that Helpdesk functionality (as lost passwords) is handled
securely.
Guiding principles by OWASP.
Verify that the server is updated with all known patches
for buffer overflows


Discuss this with Web Admin to ensure that any applicable patches have
been installed.
In certain cases, commercial web applications require their own patches
separate from the web platform.
Review the website for Cross-Site-Scripting (XSS)
vulnerabilities




Best method is to do a thorough code review with the Admin.
Validate every header, cookie, query string, form field and hidden field.
Tools like Nikto and Nessus can find well known attacks, but they are not as
good as performing a solid code review.
Consider hiring third-party help if you require resources.
Ensure Web Application is protected against Injection
attacks




Validate all input using positive validation methods (what input should be).
Perform code review if possible for all calls to external resources to
determine if the method could be compromised.
Commercial tools help finding well-known attacks, but not as good as code
review.
Consider hiring 3rd party help if application is particularly sensitive.
Evaluate the use of proper error handling.



Discuss with Admin how error handling is designed into the Web App.
Error handling is often better controlled if it is centralized as opposed to
compartmentalizing across several interworking objects/components.
If you are reviewing the code, the error handling should flow nicely and
show structure.
Ensure that secure storage mechanisms are used correctly
and appropriately.



If data are sensitive and not encrypted, consider whether there are industry
/ regulatory drivers stating that the data must be encrypted & note the
issue.
If encrypted, understand how the encryption mechanism was implemented.
Ensure that the level of encryption is equivalent to the level of data you
want to protect (for extremely sensitive data – have actual encryption
instead of a simple algorithm that obfuscates the data).
Determine the use of adequate controls to prevent DOS.




Authenticated users would have more resources and visiting users would be
limited in scope as to what they can access.
Resource-intensive operations in some cases may be offloaded, such as DB
queries.
Make sure that your Hardware and Memory are sufficient for the Web
Application.
You can use open-source stress-testing tools.
Review controls surrounding maintaining a secure
configuration

Discuss the following with Admin to ensure proper configuration
management controls are in place:
– Security mailing lists for web server, platform, and application are
monitored.
– Latest security patches are applied.
– VA Scan from both internal and external perspectives is conducted.
– A security configuration guideline exists for the web servers and is
strictly followed.
– Regular internal reviews of the server’s security configuration are
conducted.
– Regular status reports are issued to upper management documenting
overall security posture of the web servers.
Some Web Application Testing Tools

iMacros - tool from iOpus.com (free trial)

Burp Suite - an integrated platform for attacking web applications.

AppScan - from IBM offers static and dynamic security testing in all
stages of application development. (trial download)

HP WebInspect - web application security testing for complex web
applications. (15 days evaluation)
A presentation on
Basics of Web Application
Vulnerabilities - Best Practices
By
Kishore Kumar M , M.Sc(IS), CISA, E-MBA, CSM
References:
 www.owasp.org
 http://advosys.ca/papers/web/61-web-security.html

‘IT AUDITING Using Controls To Protect Information Assets’ – By Chris Davis, Mike Schiller,
and Kevin Wheeler
Thank You