230 likes | 329 Views
Web Security. Overview I. Original purpose Linking documents Documents include links to other documents User “browses” these documents HTML – special language that includes such “hypertext” links Uniform Resource Locator (URL ) Domain (as in DNS) – www.bgu.ac.il File path in domain
E N D
Overview I • Original purpose • Linking documents • Documents include links to other documents • User “browses” these documents • HTML – special language that includes such “hypertext” links • Uniform Resource Locator (URL) • Domain (as in DNS) – www.bgu.ac.il • File path in domain • Server – holds HTML pages in directory structure • Client requests pages
Overview II • HTTP protocol • Main versions: 1.0 and 1.1 • Stateless request-response protocol • Originally, client sent HTTP GET requests with URL, server responded with HTML page • Graphical browsers – show rich content • Richer HTML, resources include • Embedded media files • Client-side scripts, e.g. Javascript • Flash • Many more
Overview III • HTTP evolution • Richer request format, e.g. POST method • State storage – web cookie • Authentication protocols – password based • Server evolution • Run programs on parameters supplied by client in URL or forms • Return answers based on user input • Complex scripting languages – e.g. PHP • Connection to databases • Web is rich platform for applications • Commerce, health, entertainment, communication etc.
Threats • Users & servers • Impersonation, eavesdropping, traffic modification • Authorization problems – reading and writing unauthorized data, running malicious software • Cross-site issues • Users • Privacy concerns • Servers • DoS • Stealing web pages • PR problems • Legal issues
OWASP top 10 • A1: Injection • A2: Cross-Site Scripting (XSS) • A3: Broken Authentication and Session Management • A4: Insecure Direct Object References • A5: Cross-Site Request Forgery (CSRF) • A6: Security Misconfiguration • A7: Insecure Cryptographic Storage • A8: Failure to Restrict URL Access • A9: Insufficient Transport Layer Protection • A10: Unvalidated Redirects and Forwards
TLS overview • Intent – create secure tunnels over TCP • Specified in RFC 2246 (version 1.0), RFC 4346 (version 1.1), RFC 5246 (version 1.2) • Two phases • Handshake (authentication, key exchange, cipher-suite agreement, creation of shared key) • Application data (encrypted and integrity protected) • Authentication method – certificate based • Authenticated parties: either one-way (only server) or both parties
TLS in IP stack Applications HTTP HTTPS Native support TLS Other UDP TCP IP MAC
TLS Layering Cert Key exchange … Application Data Alert C.C.S Handshake Record Layer
Client Key exchange Client Hello Server Authentication And key exchange Finished Application data TLS messages Client Server
Virtual servers problem Server1 Abc.com Server2 Hi.com Server3 Bye.com TLS layer TCP:443 IP layer
Cookies • Invented by Netscape (1994) • Used to store state • Web servers choose what to store • Recommended length – 4096 bytes • Examples (RFC 6265) • Server -> User Agent • Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly • Set-Cookie: lang=en-US; Path=/; Domain=example.com; Expires=Wed, 09 Jun 2021 10:18:14 GMT • User Agent -> Server • Cookie: SID=31d4d96e407aad42; lang=en-US
Usage and attributes • Session cookies – authentication and authorization with one string • Persistent cookies - “expires” in the future • Secure – sent by browser over HTTPS only (or any other secure channel as defined by the browser) • Httponly – sent in HTTP requests, not exposed to user-side scripts, e.g. HTML document.cookie • Stops most XSS exploits • Does not stop cross-site tracing. In HTTP trace, all HTTP headers, including the cookies are sent • Domain – specifies authorized domain for cookies • Only domains that include the current site are allowed
Cookies and security • HTTPS does not provide full protection for cookies against MITM, because http:// can be substituted for https:// • Are encryption and integrity needed for a cookie? • None at all? Symmetric key? Public key? • Cookies may be specified for public domains, e.g. .com or .ac.il • Sister domains may not be trusted, e.g. bgu.ac.il and tau.ac.il • Cookies as identifiers to server side database • Information is not exposed in cookie, but server maintains the information on the clients
Cookies and privacy • Tracking cookies • Correlate information on user between visits to site • 3-rd party cookies • Example – advertising • Track users across multiple sites • Browsers can refuse 3-rd party cookies • Tracking can be achieved by dynamic URLs instead of such cookies • Zombie cookies • Stored outside cookie cache – regenerated after deletion • HTTP ETags – server generates tag for resource and changes tag when resource changes. Tags used for caching
More on Zombies • HTML 5 • New HTML standard – making web applications easier and better • Big feature – localStorage object – stores data across sessions to site (larger than cookie) • Local shared Objects (flash cookies) – cookie functionality for Flash • Zombie cookies refresh all storage locations once web site is visited again • Lawsuit (2011) – against Disney, Warner Bros. etc. on zombie cookies
Web bugs • Usually invisible objects (e.g. pixel sized images) • Browsing web page or viewing e-mail with web bug causes a request for object • Usage • Track if page or e-mail is viewed • Track user by cookie attached to bug • Check if page is served at another site • E-mail web bugs – check that e-mail address is valid, IP address, time of viewing etc. • This is why most modern e-mail clients turn-off images by default
CSRF • Cross Site Request Forgery • Site X has link to site Y exploiting site Y’s trust in the user • Example • User has open session with site Y • Link parameters form HTTP request to site Y.
Directory Traversal • Used to access directories outside the public web site • Example: www.bgu.ac.il/../../../ … • Standard defense: look for ../ In URL • Percent encoding • %2e%2e%2f encodes ../ • Unicode • Used to encode various languages • May use more bytes to encode characters • %c1%1c encodes /
Traversal in parameters • Example • http://www.portal.co.il/online/getnews.asp?item=../../../../ important_file
HTTP response Splitting • Attacker, target server setup as in XSS • HTTP headers are separated by sequence of carriage return (CR, \r, ASCII 0x0D) and line feed (LF, \n, 0x0A) • HTTP headers in response separated from body by two CRLF • Attack – user supplies data with CRLF and after that supplies arbitrary HTTP headers and body • Usage • XSS • Cross user attacks • Cache poisoning
HTTP Response Splitting (cont.) • Another approach • Attacker sends two requests through target • The second HTTP response is matched to the second HTTP request