web application security (part 1)new.dcs.fmph.uniba.sk/files/biti/webapp1-2019.pdf ·...

Web Application Security(Part 1)

Richard Ostertág

Department of Computer ScienceComenius University, [email protected]

2016/17

R. Ostertág (DCS, Comenius University) Web Application Security (1) 1 / 35

The web sites era (Web 1.0)

I static documentsI browsers used only for retrieving and displaying those documentsI one-way flow of “interesting” information (server → browser)I typically without user authenticationI every user: equal treatment, the same contentI users do not create presented contentI security threats abused mainly vulnerabilities in the web server

softwareI compromised server

I no leakage of sensitive information (all info. already open to public)I modification of contentI server’s storage and bandwidth used to distribute “warez”


The web applications era (Web 2.0)

I interactive dynamic applicationsI the browser becomes the operating system, which runs the web

applicationI two-way flow of “interesting” information (server ↔ browser)I usually there is users authentication (registration, login)I each user: different treatment, different personalized contentI users are creating presented contentI security threats are abusing also vulnerabilities in web applicationI compromised server / web application

I leakage of sensitive information (personal data, credit card numbers)I modification of content (money defrauding, attacks on other users)I use of bandwidth, processing power or storage capacity

I e.g. for creating botnets to send spam or DDoS attacks


Common internet web application functionsI Internet stores

I AmazonI HejI Alza

I Social networksI FacebookI TwitterI Second life

I Internet bankingI TatrabankaI VÚBI Slovenská sporiteľna

I Search enginesI GoogleI BingI Baidu

I Internet auctionsI eBayI Aukro

I Internet casinosI bwin

I Web logsI Blogger

I Web mailI GmailI Hotmail

I Internet mediaI CNNI SME

I Internet encyclopediaI Wikipédia


Common intranet web application functions

I HR applicationsI payroll informationI recruitmentI disciplinary procedures

I Key infrastructureadministrative interfacesI web serverI mail serverI virtualization server

I Collaboration softwareI document sharingI project management

I Business applicationsI Enterprise Resource PlanningI Customer Rel. Mangement

I Software servicesI e-mail web interface

I Traditional desktop applicationsmigrated to the webI word processorsI spreadsheets


Common web application vulnerabilities

broken authentication 62%broken access controls 71%SQL injection 32%cross-site scripting 94%information leakage 78%cross-site request forgery 92%

Source: Dafydd Stuttard, Marcus Pinto: The Web Application Hacker’s HandbookR. Ostertág (DCS, Comenius University) Web Application Security (1) 6 / 35

SSL, PCI – false sense of securityI users are aware of security issues in web applicationsI most applications state that they are secure because they use SSL1:

This site is absolutely secure. It has been designed to use 128-bit SecureSocket Layer (SSL) technology to prevent unauthorized users fromviewing any of your information. You may use this site with peace ofmind that your data is safe with us.

I organizations also cite their compliance with Payment Card Industry(PCI) standards:We take security very seriously. Our web site is scanned daily to ensurethat we remain PCI compliant and safe from hackers.I use and maintain a firewallI do not use default passwordsI encrypt data transfered over public networksI maintain security policyI . . .

1Source: Dafydd Stuttard, Marcus Pinto: The Web Application Hacker’s HandbookR. Ostertág (DCS, Comenius University) Web Application Security (1) 7 / 35

The core security problem

I attacker can submit arbitrary responseI client side safety checks can be circumventedI attacker does not need to use a web browser to access the applicationI attacker (on the client side) can:

I read, modify, delete, or reuse any data that received from the server orweb-browser is sending to the server

I generate new data and inject them into the communicationI manipulate (suppress, modify, repeat) any operations performed on the

client sideI an attacker can manipulate all kinds of data the client operates with:

I URL (path parts, GET parameters)I form fields (even hidden)I commented out parts of HTML documentsI scripts (review, change)I cookies and other information in HTTP headers (e.g. session ID)

I it must be assumed that all inputs are potentially dangerous


Key problem factorsI underdeveloped security awareness

I field of web application security is relatively young (vs. networks, OS)I custom development

I many web applications are developed in-house by an organization’s ownstaff with different skills

I every application is different and may contain its own unique defectsI deceptive simplicity

I a novice programmer can create a powerful application from scratchI difference between producing functional code and secure code

I new threats for web applications are conceived at a faster rate than isnow the case for older technologies

I resource constraints (time, money, developers, . . . )I functionality takes precedence over the security

I overextended technologiesI many of the core technologies employed in web applications have been

pushed far beyond the purposes for which they were originallyconceived and unforeseen side effects emerge


Core defense mechanisms

I user access controlI prevent users from gaining unauthorized access

I user input validationI prevent unwanted behavior of application even for malicious entry

I handling attackI correct functionality even in the event of a direct attackI defensive and offensive measures to repel the attack

I application monitoringI administrator can react immediately


User access control

I basic components:I identification and authenticationI session management

web application issues a token that identifies the user sessionI access control

I fault in any component may lead to unauthorized access


Identification and authentication

I identificationI most often by login name

I authenticationI most often with a password

I the attacker canI obtain login namesI obtain passwordsI bypass the authentication function

I due design flaw


Identification and authentication (the classic problems)I weak passwords

I shortI small alphabetI from dictionaryI guessable (date of birth)

I quality control (e.g. a dictionary attack)I the same password to different systemsI no time limit for password age

I password age checksI keylogger

I virtual keyboardI one-time passwordsI zero knowledge proofs

I late transition from HTTP to HTTPSI failed login should not differentiate bad name from bad password


Session management – session hijacking2

I disclosure of session identifierI interception of communicationI “Referer” header when switching to other sitesI browser historyI access to the user’s computer – extraction of stored cookies, . . .

I session ID guessingI identifier is generated in a predictable manner

(for example simple arithmetic progression)I identifier has a small range of possible values

I possible protection:I protection is not easy and 100% effectiveI identifier is not just a random numberI concatenated with the hash of the IP address of the server and the

client, User-Agent header of the client and some secret valueI then the attacker can not simply use a stolen ID

2attacker finds ID of another session and through this ID he is able to join that session andworks under another identity


Session management – cross-site request forgery (CSRF)

I cross-site request forgery, aka. a one-click attack or session ridingI session hijacking requires that the attacker has stolen or guessed IDI session riding does not require knowledge of the session ID

I attacker convinces a user to send him constructed requestI convinces him to click on link he created (e.g. in discussion)I images can send requests too (automatically)

I possible protection:I not using cookies to store session IDI place session ID directly into the URLI randomly generate and embed authentication tokens to each action

URL


Access control

I authenticated users can have access only to certain parts of the siteI attacker can gain unauthorized access using programmers wrong

assumption about how users will interact with the applicationI URL tampering – altering parts (especially the GET parameters) of

existing URLI if the attacker sees URL in the form:

https://www.app.sk/zaznam.php?id=1234I he can try to enter a URL in the form:

https://www.app.sk/zaznam.php?id=1235I Forceful browsing – creation of new URLs

I attacker can try to enter a URL like:https://www.app.sk/zaznam.php.old

I or it may try to enter, for example:https://www.app.sk/admin.php

I server relies on fact: client can request only URL sent to him


Input validation – different approachesI reject dangerous inputs

search for known patterns used in attacksI accept safe inputs (allow specified harmless inputs)I input sanitization

I eliminate potential dangerous character sequences (e.g. <script>)I ’<scr<script>ipt>’ ?I ’+ADw-script+AD4-’ ?

I secure input processingI parameterized database queries

I semantic checksI input data are syntactically correct (eg account number)I but not semantically (not my account number)

I input must be validated on the server sideI although for a better UX checks are done also on the client sideI best to revalidate in each part of the application


Code injection

I each language has a specific syntax and specific control charactersI web applications often use different languages

(e.g.: SQL, HTML, JavaScript, XML, HTTP, . . . )I unexpected side effects can emerge if untreated data from the client

are inserted into the program in any of these languagesI SQL injectionI XPath injectionI HTML injection (markup injection)

CSRF, XSRF: cross-site request forgeryI JavaScript injection

XSS: cross-site scripting


SQL injection

I select * from Pouzivatelia where Meno=’Janko Hrasko’I input: ’ or ’’=’

select * from Pouzivatelia where Meno=’’ or ’’=’’

I input: ’ and 1=0 union all select * from Tabulka--select * from Pouzivatelia where Meno=’’ and 1=0 union all select * from Tabulka--’

I sometimes the application returns only part of the result or returninformation only indirectlyI error messageI request processing time


SQL injection – real example :-)


XPath injection

I //user[name/text()=’Janko Hrasko’ and password/text()=’passwd’]/account/text()

I input: ’ or 1=1 or ’’=’//user[name/text()=’’ or 1=1 or ’’=’’ and password/text()=’passwd’]/account/text()

I input: NoSuchUser’] | P | //user[name/text()=’NoSuchUser//user[name/text()=’NoSuchUser’] | P | //user[name/text()=’NoSuchUser’ andpassword/text()=’passwd’]/account/text()first and last part return nothing =⇒ result is the evaluation of P

I in XPath it is not possible to apply access rights (within tags)I therefore, the second way can get the entire XML documentI on the other hand, during the SQL injection, attacker will be restricted

solely to the tables where a given application has access


Session cookieI HttpOnly not set

I this property prevents client-side scripts from accessing the cookieI Overly broad session cookie domain/path

I attack through other applications sharing the same domain/pathI Persistent session cookie

I remains valid even after a user closes browserI often used as part of a “Remember Me” feature

I not sent over SSLI Modern web browsers support a secure flag for each cookie.

I If the flag is set, the browser will only send the cookie over HTTPS.I If an application uses both HTTPS and HTTP without the secure flag,

I then cookies set during an HTTPS request will also be sent duringsubsequent HTTP requests.

I DisabledI If the program does not use cookies to transmit session ID,

I then ID is transmitted as an request parameter or as part of the URL.I Leaves the door open to session fixation and session hijacking attacks.


System misconfiguration

I Least privilege violationI Password management

I Empty, hard-coded or default passwordI Password in config file

I UnprotectedI Protected by weak cryptography

I System information leakI Missing custom error pageI Improper use of SSL

I Weak ciphers or protocolsI Self-signed certificates


Insecure programming

I Buffer overflow, integer overflow, format stringI Exception handling

I Empty catch block, i.e. ignoring exceptionsI Overly-broad catch block (promotes complex error handling code)

I Insecure randomnessI Failure to begin a new session upon authenticationI File access race condition (TOCTOU)I Pointers

I Double freeI Use after freeI Memory leakI Null dereference

I Leftover debug code


Insecure compiler optimization – memset

I Secret data is stored in memory.I The secret data is cleared from memory by overwriting its contents.I The source code is compiled using an optimizing compiler.I The compiler identifies and removes clearing as unnecessary because

the memory is not used subsequently.


Insecure compiler optimization – memset example

1 # include <stdio.h>2 # include <string.h>3

4 void clear(void) {5 char pwd[257];6 gets(pwd);7 memset(pwd, 0, sizeof(pwd));8 puts(pwd); // we will comment this line later9 }


Insecure compiler optimization – with puts1 clear(): # @clear()2 pushq %rbx3 subq $272, %rsp # imm = 0x1104 leaq (%rsp), %rbx5 movq %rbx, %rdi6 callq gets7 xorl %esi, %esi8 movl $257, %edx # imm = 0x1019 movq %rbx, %rdi

10 callq memset11 movq %rbx, %rdi12 callq puts13 addq $272, %rsp # imm = 0x11014 popq %rbx15 retq


Insecure compiler optimization – without puts1 clear(): # @clear()2

3 subq $264, %rsp # imm = 0x1084 leaq (%rsp), %rdi5

6 callq gets7

8

9

10

11

12

13 addq $264, %rsp # imm = 0x10814

15 retq


Insecure compiler optimization – pointer arithmetic

I An arithmetic overflow on a pointer is undefined behavior.I Array bounds check could be mistakenly optimized out.I If an array bounds check involves computing an illegal pointer and

then determining that the pointer is out of bounds, some compilerswill optimize the check away.


Insecure compiler optimization – pointer arithmeticI Following C code:

1 # include <stdio.h>2

3 void wrap(unsigned long len) {4 char *buf;5

6 if (buf + len < buf)7 puts("OK");8 }

I translates to:1 wrap(unsigned long): # @wrap(unsigned long)2 retq

I Even if buf + len < buf is possible (check for arithmetic overflow)call to puts is optimized away.


Handling attacks

I developers must assume that application will be directly targeted bydedicated and skilled attackers

I handling attacks requires:I handling errorsI audit logsI alerting administratorsI reacting to attacks


Handling attacks – handling errors

I it is virtually inevitable that some unanticipated errors will occurI it is difficult to anticipate every possible way in which a malicious user

may interact with the application

I application should handle unexpected errorsI recovering from errorI presenting an appropriate error message

I administrator – detailedI user – brief


Handling attacks – audit logs

I invaluable source of information when investigating intrusion attemptsI logs help to detect:

I what happenedI what vulnerabilities were exploitedI which data have been stolenI the attacker’s identity

I the following events should always be recorded:I successful and failed loginI change of passwordI important transactions (e.g. funds transfers)I access attempts that are blocked by the access control mechanismsI requests containing known attack strings

I indicate overtly malicious intentions


Handling attacks – alerting administrators

I administrators can solve the problem online (instead of retrospectiveoffline analysis)I block attackers IP addressesI set up a trap

I warning should come if:I untypical usage

I a large number of requests from a single IP in a short timeI a large number of transfers of funds from different accounts into a

single accountI client responses / requests contains

I known attacks patternsI changed hidden data (from normal users)


Handling attacks – reacting to attacks

I system can react automatically byI attackers session terminationI slowing the response to the attacker’s IP addressI blocking the attacker’s IP addressI warning attacked user

I more time for administrators


web application security (part 1)new.dcs.fmph.uniba.sk/files/biti/webapp1-2019.pdf ·...

Documents