Writing Secure Web Applications
Transcript of Writing Secure Web Applications
-
8/8/2019 Writing Secure Web Applications
1/59
Writing Secure Web ApplicationsAndreas Wiegenstein - Chief Technical Officer
-
8/8/2019 Writing Secure Web Applications
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
-
8/8/2019 Writing Secure Web Applications
3/59
>>
>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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
-
8/8/2019 Writing Secure Web Applications
4/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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
-
8/8/2019 Writing Secure Web Applications
5/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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
-
8/8/2019 Writing Secure Web Applications
6/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Know Your Enemy - How Hackers "Work"
Types of attackers:
Hackers
Script Kiddies
Social Engineers (Disgruntled) Employees
-
8/8/2019 Writing Secure Web Applications
7/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Know Your Enemy - How Hackers "Work"
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/8/2019 Writing Secure Web Applications
8/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Know Your Enemy - How Hackers "Work"
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
-
8/8/2019 Writing Secure Web Applications
9/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Know Your Enemy - How Hackers "Work"
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.
-
8/8/2019 Writing Secure Web Applications
10/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Know Your Enemy - How Hackers "Work"
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
-
8/8/2019 Writing Secure Web Applications
11/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Know Your Enemy - How Hackers "Work"
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
-
8/8/2019 Writing Secure Web Applications
12/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Know Your Enemy - How Hackers "Work"
Stages of an attack
Reconnaissance
Data analysis
Attack preparation Attack
Clean up
-
8/8/2019 Writing Secure Web Applications
13/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Know Your Enemy - How Hackers "Work"
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
...
-
8/8/2019 Writing Secure Web Applications
14/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Know Your Enemy - How Hackers "Work"
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
-
8/8/2019 Writing Secure Web Applications
15/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Know Your Enemy - How Hackers "Work"
Stages of an attack - Attack preparation
determine how the applications reacts to unexpected input
try tricking the application logic
deduce attack patterns
-
8/8/2019 Writing Secure Web Applications
16/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Know Your Enemy - How Hackers "Work"
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
-
8/8/2019 Writing Secure Web Applications
17/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Know Your Enemy - How Hackers "Work"
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
-
8/8/2019 Writing Secure Web Applications
18/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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
-
8/8/2019 Writing Secure Web Applications
19/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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)
-
8/8/2019 Writing Secure Web Applications
20/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Web Application Characteristics
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
-
8/8/2019 Writing Secure Web Applications
21/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Web Application Characteristics
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
-
8/8/2019 Writing Secure Web Applications
22/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Web Application Characteristics
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
-
8/8/2019 Writing Secure Web Applications
23/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Web Application Characteristics
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
-
8/8/2019 Writing Secure Web Applications
24/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Web Application Characteristics
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
>>
>>
-
8/8/2019 Writing Secure Web Applications
25/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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
>>
>> Attack & Defense Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
26/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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
>>
>> Attack & Defense Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
27/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Attack & Defense - Threats and Best Practices
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.
>>
>> Attack & Defense Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
28/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Attack & Defense - Threats and Best Practices
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
-
8/8/2019 Writing Secure Web Applications
29/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Attack & Defense - Threats and Best Practices
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
>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
30/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Attack & Defense - Threats and Best Practices
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>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
31/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Attack & Defense - Threats and Best Practices
In-Band Signaling - Cross-Site Scripting (XSS) example attack
Data entered in the field "user name":
document.write('
');document.hack.submit();
Smith
>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
32/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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
>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
33/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Attack & Defense Threats and Best Practices
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 + "");}
...
}
>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
34/59
>>>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Attack & Defense Threats and Best Practices
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
>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
35/59
>>
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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
>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
36/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
In-Band Signaling - SQL injection [ contd ]
Best practices:
validate input
remove/escape the character' in strings
>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
37/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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;
}
...
>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
38/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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.
>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
39/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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]
>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
40/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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.
>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
41/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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)
Information Disclosure
Elevation of Privilege
Best practices:
All sensitive resources must be protected by strict access
control.
>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
42/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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/
>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
43/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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.
>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
44/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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.
>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
45/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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.
>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
46/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Fault Induction
Threat:
Error conditions are forced by manipulated input in order to
deduce information.
Risk:
Information Disclosure
Best practices:
Use proper input validation.
Display only general messages like "Invalid input" or "An error
has occurred."
>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
47/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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.
-
8/8/2019 Writing Secure Web Applications
48/59
>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
49/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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
>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
50/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Cookie Poisoning
Threat:
Application data stored in a cookie might be manipulated.
Risk:
Tampering with Data
Information Disclosure
Best practices:
Don't rely on data stored in cookies (they are input) ...
...unless this data is protected by cryptography (SSO2 ticket)
>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
51/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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
>>
>> Attack & Defense - Threats and Best Practices
-
8/8/2019 Writing Secure Web Applications
52/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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.
>>
>>
-
8/8/2019 Writing Secure Web Applications
53/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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
>>
>> General Best Practices
-
8/8/2019 Writing Secure Web Applications
54/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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
-
8/8/2019 Writing Secure Web Applications
55/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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.
>>
>>
-
8/8/2019 Writing Secure Web Applications
56/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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
-
8/8/2019 Writing Secure Web Applications
57/59
>>
>>
-
8/8/2019 Writing Secure Web Applications
58/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
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
>>
>> Q & A
-
8/8/2019 Writing Secure Web Applications
59/59
Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein
Thank you for your attention.