writing secure web applications

8/8/2019 Writing Secure Web Applications

1/59

Writing Secure Web ApplicationsAndreas Wiegenstein - Chief Technical Officer


2/59

>>

>>

Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein

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


3/59

>>

>>


Security Statements






Q&A


4/59

>>>>


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 itscomponents/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


5/59

>>>>


Security Statements






Q&A


6/59

>>>>



Types of attackers:

Hackers

Script Kiddies

Social Engineers (Disgruntled) Employees


7/59

>>>>



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


8/59

>>>>



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


9/59

>>>>



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.


10/59

>>>>



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


11/59

>>>>



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


12/59

>>>>



Stages of an attack

Reconnaissance

Data analysis

Attack preparation Attack

Clean up


13/59

>>>>



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

...


14/59

>>>>



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


15/59

>>>>



Stages of an attack - Attack preparation

determine how the applications reacts to unexpected input

try tricking the application logic

deduce attack patterns


16/59

>>>>



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


17/59

>>>>



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


18/59

>>>>


Security Statements






Q&A


19/59

>>>>



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)


20/59

>>>>



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


21/59

>>>>



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

>>

C


22/59

>>>>



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

>>

W b A li ti Ch t i ti


23/59

>>>>



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 acertain context. Only the web application knows that context.

>>

>> W b A li ti Ch t i ti


24/59

>>>>



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

>>

>>


25/59

>>>>


Security Statements






Q&A

>>

>> Attack & Defense Threats and Best Practices


26/59

>>>>



In-Band Signaling

Cross-Site Scripting

SQL injection

OS command injection

Forceful Browsing

Session Hijacking

Fault Induction

Directory Traversal

Cookie Poisoning

>>



27/59

>>>>



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 controlinstructions from the data, resulting in Unwanted Command

Execution.

Risk: arbitrary command execution on the server

Best practices:

metadata and control instructions must be escaped.

>>



28/59

>>>>



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 differentsecurity context.

Risk:

Tampering with Data execution of ActiveX commands

Information Disclosure

Stolen Cookie (SSO2 ticket)

Stolen data (Redirected forms)

>>

>> Attack & Defense - Threats and Best Practices


29/59

>>>>



In-Band Signaling - Cross-Site Scripting (XSS) [ contd ]

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

>>



30/59

>>>>



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("
Applicant:" + s + "");

}

...

}

Supposed output:

Applicant:Smith

>>



31/59

>>>>



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

Data entered in the field "user name":

document.write('

');document.hack.submit();

Smith

>>



32/59

>>>>


Attack & Defense Threats and Best Practices

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

HTML output containing the applicants input, rendered in the

companies intranet:

Applicant:

document.write(

');

document.hack.submit();

Smith

Visible output:Applicant: Smith

>>



33/59

>>>>



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("
Applicant:" + s + "");

}

...

}

>>



34/59

>>>>



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

SAP System

WAS/ABAP: cl_http_utility->escape_html

EP5/EP6: several methods in class StringUtils

HTMLB: implicit protection

Web Dynpro: implicit protection

>>



35/59

>>


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 Information Disclosure

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

>>



36/59


In-Band Signaling - SQL injection [ contd ]

Best practices:

validate input

remove/escape the character' in strings

>>



37/59


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;

}

...

>>



38/59


In-Band Signaling - SQL injection example data

(valid credentials)

URLhttp://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.

>>



39/59


In-Band Signaling - SQL injection example attack and result

(#1: unexpected "credentials")

URLhttp://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]

>>



40/59


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 theweb 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 userinput.

>>



41/59


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)

Information Disclosure (resource is a page)


Elevation of Privilege

Best practices:

All sensitive resources must be protected by strict access

control.

>>



42/59


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/

>>



43/59


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.

>>



44/59


Session Hijacking

Threat:

An attacker might deduce another users session ID from hisown.

Risk:

Spoofing

Tampering With Data

Information Disclosure Elevation of privilege

Best practices:

Use proven industry standards that have been reviewed byexperts.

If you must create your own session management, consult acryptographic expert.

>>



45/59


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.

>>



46/59


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."

>>



47/59


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.


48/59

>>



49/59


Directory Traversal example

Application URLhttp://www.example.com/main.asp?disp=start.html

(Information deduced from Fault Induction)

Resource "start.html" resides in the folder"c:\app\html"

Exploithttp://www.example.com/main.asp?disp=..\..\winnt\win.ini

>>



50/59


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)

>>



51/59


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

>>



52/59


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.

>>

>>


53/59


Security Statements






Q&A

>>

>> General Best Practices


54/59


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 regularbasis.

Make security a priority

...because if you don't find the bugs in your systems, someoneelse will.

Remember: one flaw is all the attacker needs

>>

>> General Best Practices


55/59


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 anindependent (external) team.

>>

>>


56/59


Security Statements






Q&A


57/59

>>

>>


58/59


Security Statements






Q&A

>>

>> Q & A


59/59


Thank you for your attention.

writing secure web applications

Documents