1 / 23

Web Security

Web Security. Sandy Kutin CSPP 532 8/7/01. Web security: an overview. Company wants to build web site Online purchasing Requests for service or support Viewing data files online How do we make this process secure? Confidentiality Authentication Usual answer: cryptography.

ovidio
Download Presentation

Web Security

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Web Security Sandy Kutin CSPP 532 8/7/01

  2. Web security: an overview • Company wants to build web site • Online purchasing • Requests for service or support • Viewing data files online • How do we make this process secure? • Confidentiality • Authentication • Usual answer: cryptography

  3. Applications TCP IP TCP/IP in 60 seconds • Computers communicate via packets, not connection • Packets are directed from machine to machine • Smart nodes, stupid network • Contrasts with phone network • Internet Protocol controls this movement • Transfer Control Protocol: packets at destination • Could insert cryptography at any layer

  4. Applications TCP IPsec IPsec • IPsec works at IP level • Transparent to applications • Slows everything down • Some say it’s the future, some say it’s not • If every packet is encrypted: negates performance-optimization, firewalls

  5. Applications SSL Record TCP IP HaSSLe-free Solution • Secure Sockets Layer (SSL) • Works at TCP level • Developed by Netscape • “Applications” now includes: • Handshake, Alert, Cipher Spec Change • Packets encoded by SSL Record Protocol • Implemented in web server, browser • Successor: Transport Layer Security (TLS)

  6. LoSSLess Communication • SSL Record Protocol: • 1. Fragment data into blocks; can compress • 2. Append MAC to each block: • MAC = H(K | pad2 | H(K | pad1 | info | data)) • H could be MD5 or SHA-1; similar to HMAC • info includes sequencing, length information • 3. Encrypt each block (symmetric) • 4. Append header, send fragment

  7. BusineSSLike Handshake • How do we establish a session key? • 1. Client says “hello”: version, random number • 2. Server says “hello”: same, includes key exchange method, optional certificate • 3. Client initiates key exchange (may just generate master, send it using RSA) • 4. Both sides compute various keys from master, random numbers in hello messages • 5. Confirmation messages

  8. HelpleSSLy Hoping • So, does SSL secure our site? • Confidential, authenticated transactions are important, but not the only issue • Threat model: who might attack, and how • Steal customer data (credit cards) • Steal private corporate data • Deface web site • Denial of Service: prevent us from working • SSL has nothing to do with any of these

  9. Trial Separation • How do we keep corporate data secure? • Solution: keep it separate • Only mix information when you have to: use a floppy, or a laptop • Partial solution: restrict web server’s access privileges (e.g., firewall, DMZ) • OK if data flow is mostly to the server • What about credit card numbers?

  10. Bob Alice Stallings, page 464 (from the web site)

  11. SET, I project • Secure Electronic Transaction (SET) • MasterCard, Visa • Alice sends Bob order, encrypted card info • Bob forward card info to MC/Visa • MC/Visa pays Bob • Bob never gets card number • Credit card company never gets order information

  12. Building a Better MouSETrap • OI = order info (include time), OIMD = H(OI) • PI = payment info (& time), PIMD = H(PI) • Alice signs (OIMD | PIMD) (SHA-1, RSA) • Alice sends Bob OI, ECC(PI), PIMD, sig S • Bob compute OIMD, checks signature S • Bob sends OIMD, ECC(PI), S to MC/Visa • They decrypt, check PI, check signature S • They transfer funds, Bob ships item to Alice

  13. Improving our MindSET • Think outside the box • Q: How do we store credit card numbers? • A: Store them so we can’t read them • Application-level solutions: harder to implement, but better targeted to problems • Cryptography is only part of the solution • Any system can be broken • Build a threat model, measure costs

  14. Breaking and Entering • Enemy could break in • Could corrupt data (deface web site) • Could steal data (including passwords) • Could gain control of system • Firewalls help, but there’s always a way in • Keep data separate whenever possible • Educate users about viruses, Trojan horses • Install patches as often as you can

  15. Intruder Alert • Home security: locks stop easy attacks • Better: door, window alarms • (as long as they don’t go through the walls) • Even better: motion detectors • Alarms don’t stop anything directly, but they alert the authorities • Fear of alarms forces criminals to hurry, make mistakes

  16. Law and Order • Deterrent to robbery: fear of prosecution • After a crime, police gather fingerprints, DNA, eyewitnesses • Not aimed at stopping crime or recovering goods, but at punishing criminals • Hard to do in computer crime; criminals often minors or foreign nationals

  17. Intrusion Detection • No matter what systems and protocols we use, people will break in if they want • Hard to defend against determined teenagers with nothing else to do • Solution: monitor system, detect intrusions, watch for unusual activity • Honeypots: trap intruders • Gather evidence; maybe prosecute • At the very least, close off the holes

  18. Denial of Service Attacks • One approach: break in, crash the server • Another: flood the server with bad requests • Distributed Denial of Service (DDoS): • Take over PCs around the country/world • Use them to overload a site • Only solution: have hardware routers detect bad packets • Almost impossible; Windows XP may make it worse

  19. Here’s looking at you, KiDDoS • In the real world: to attack, you have to put yourself at risk. Not on the Internet. • In the real world: attackers must learn skills. Not on the Internet. • One person discovers a hole, writes a script; now “script kiddies” can use it • Patches don’t work. Attackers will always be ahead of users. • Beta testing doesn’t uncover security holes

  20. Gibson Research Corporation • Steve Gibson’s GRC.com: security • Attacked, repeatedly, by DDoSs. No defense. “Nothing more than the whim of a 13-year old hacker is required to knock any user, site, or server right off the Internet.” • Solution: Distributed Responsibility • Owners responsible for their machines • ISPs responsible for their routers • Software writers responsible for bugs

  21. EXPensive Problem • Attackers usually spoof source IP addresses, to conceal their location • Easy to do in UNIX (as root) • Not possible in Windows 9x/ME, but possible in Windows 2000/XP • Microsoft says: we’re fixing a bug • Gibson says: there’s no legitimate reason home users would need this feature

  22. Bruce Schneier: Counterpane • Author of “Applied Cryptography” • Feels only monitoring, intrusion detection, active response can do any good • Counterpane.com: corporate security • Solution: Insurance • Insure against damages from attacks • Lower rates for following good practices

  23. Recommended Reading • Secret-sharing: • Schneier, Sections 3.7, 23.2 • SSL, SET: Stallings, Chapter 14 • General security: • Stallings, Chapters 15-16 • www.grc.com/dos/ • www.counterpane.com

More Related