Security Management in Web Applications. We all know this page...

Slides:



Advertisements
Similar presentations
1 Digest Authentication Herng-Yow Chen. 2 Outline Theory and practice of digest authentication. The improvement of Digest Authentication.
Advertisements

CP3397 ECommerce.
Spring 2000CS 4611 Security Outline Encryption Algorithms Authentication Protocols Message Integrity Protocols Key Distribution Firewalls.
Internet and Intranet Protocols and Applications Lecture 9a: Secure Sockets Layer (SSL) March, 2004 Arthur Goldberg Computer Science Department New York.
Cryptography Chapter 7 Part 4 Pages 833 to 874. PKI Public Key Infrastructure Framework for Public Key Cryptography and for Secret key exchange.
Cryptography and Network Security
SSL CS772 Fall Secure Socket layer Design Goals: SSLv2) SSL should work well with the main web protocols such as HTTP. Confidentiality is the top.
Socket Layer Security. In this Presentation: need for web security SSL/TLS transport layer security protocols HTTPS secure shell (SSH)
An Introduction to Secure Sockets Layer (SSL). Overview Types of encryption SSL History Design Goals Protocol Problems Competing Technologies.
1 Network Security Outline Encryption Algorithms Authentication Protocols Message Integrity Protocols Key Distribution Firewalls.
Grid Security Infrastructure Tutorial Von Welch Distributed Systems Laboratory U. Of Chicago and Argonne National Laboratory.
1 Supplement III: Security Controls What security services should network systems provide? Confidentiality Access Control Integrity Non-repudiation Authentication.
The Basic Authentication Scheme of HTTP. Access Restriction Sometimes, we want to restrict access to certain Web pages to certain users A user is identified.
Http Web Authentication Web authentication is used to verify a users identity before allowing access to certain web pages On web browsers you get a login.
Mar 19, 2002Mårten Trolin1 This lecture On the assignment Certificates and key management SSL/TLS –Introduction –Phases –Commands.
Mar 12, 2002Mårten Trolin1 This lecture Diffie-Hellman key agreement Authentication Certificates Certificate Authorities SSL/TLS.
Apr 22, 2003Mårten Trolin1 Agenda Course high-lights – Symmetric and asymmetric cryptography – Digital signatures and MACs – Certificates – Protocols Interactive.
User and Security Management. Security Management in Web Applications.
Encryption An Overview. Fundamental problems Internet traffic goes through many networks and routers Many of those networks are broadcast media Sniffing.
EECC694 - Shaaban #1 lec #16 Spring Properties of Secure Network Communication Secrecy: Only the sender and intended receiver should be able.
Security Outline Encryption Algorithms Authentication Protocols Message Integrity Protocols Key Distribution Firewalls.
Crawling The Web. Motivation By crawling the Web, data is retrieved from the Web and stored in local repositories Most common example: search engines,
Web Site Security Representation and Management of Data on the Web.
03 December 2003 Public Key Infrastructure and Authentication Mark Norman DCOCE Oxford University Computing Services.
Network Security – Part 2 V.T. Raja, Ph.D., Oregon State University.
Session and Security Management. HTTP Cookies Cookies Cookies are a general mechanism that server-side applications can use to both store and retrieve.
CSCI 6962: Server-side Design and Programming
Chapter 31 Network Security
SSL and https for Secure Web Communication CSCI 5857: Encoding and Encryption.
Secure Socket Layer (SSL)
Characteristics of Communication Systems
Network Security – Part 2 (Continued) Lecture Notes for May 8, 2006 V.T. Raja, Ph.D., Oregon State University.
Protecting Internet Communications: Encryption  Encryption: Process of transforming plain text or data into cipher text that cannot be read by anyone.
Cryptography, Authentication and Digital Signatures
Introduction to Secure Sockets Layer (SSL) Protocol Based on:
E-Commerce Security Professor: Morteza Anvari Student: Xiaoli Li Student ID: March 10, 2001.
Security Protocols and E-commerce University of Palestine Eng. Wisam Zaqoot April 2010 ITSS 4201 Internet Insurance and Information Hiding.
Certificate-Based Operations. Module Objectives By the end of this module participants will be able to: Define how cryptography is used to secure information.
Types of Electronic Infection
ITIS 1210 Introduction to Web-Based Information Systems Chapter 50 Cryptography, Privacy, and Digital Certificates.
Digital Envelopes, Secure Socket Layer and Digital Certificates By: Anthony and James.
1 Securing Data and Communication. 2 Module - Securing Data and Communication ♦ Overview Data and communication over public networks like Internet can.
SE-2840 Dr. Mark L. Hornick1 Web Application Security.
Internet Security. 2 PGP is a security technology which allows us to send that is authenticated and/or encrypted. Authentication confirms the identity.
1 SSL - Secure Sockets Layer The Internet Engineering Task Force (IETF) standard called Transport Layer Security (TLS) is based on SSL.
1 Security Protocols in the Internet Source: Chapter 31 Data Communications & Networking Forouzan Third Edition.
Encryption Questions answered in this lecture: How does encryption provide privacy? How does encryption provide authentication? What is public key encryption?
Advanced Database Course (ESED5204) Eng. Hanan Alyazji University of Palestine Software Engineering Department.
Lecture 16: Security CDK4: Chapter 7 CDK5: Chapter 11 TvS: Chapter 9.
CS 4244: Internet Programming Security 1.0. Introduction Client identification and cookies Basic Authentication Digest Authentication Secure HTTP.
31.1 Chapter 31 Network Security Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Encryption. Introduction The incredible growth of the Internet has excited businesses and consumers alike with its promise of changing the way we live.
PHP Secure Communications Web Technologies Computing Science Thompson Rivers University.
Network Security Continued. Digital Signature You want to sign a document. Three conditions. – 1. The receiver can verify the identity of the sender.
© Copyright 2009 SSLPost 01. © Copyright 2009 SSLPost 02 a recipient is sent an encrypted that contains data specific to that recipient the data.
COEN 350: Network Security E-Commerce Issues. Table of Content HTTP Authentication Cookies.
Mar 28, 2003Mårten Trolin1 This lecture Certificates and key management Non-interactive protocols –PGP SSL/TLS –Introduction –Phases –Commands.
Fall 2006CS 395: Computer Security1 Key Management.
Cryptographic Hash Function. A hash function H accepts a variable-length block of data as input and produces a fixed-size hash value h = H(M). The principal.
The Secure Sockets Layer (SSL) Protocol
TOPIC: HTTPS (Security protocol)
Secure Sockets Layer (SSL)
Using SSL – Secure Socket Layer
The Secure Sockets Layer (SSL) Protocol
Advanced Computer Networks
Chapter 8 roadmap 8.1 What is network security?
Presentation transcript:

Security Management in Web Applications

We all know this page...

Would we want all to what’s behind this for us? Any ideas on how access can be restricted?

Problem Want to restrict access to certain Web pages Must answer the following questions –Which pages should be restricted? –Who should access restricted pages? –How should users be authenticated? –Should data be encrypted? We consider authentication methods that ensure that the right people can access the pages

Authentication Methods: Strategies Programmatic Security: –Site designer programs the logic needed for restricting access. –very flexible –requires a lot of coding Declarative Security: –“Declare” who may access what –Use built-in HTTP mechanisms to control access (Basic or Digest access authentication scheme) –not flexible –requires little coding We will focus on Basic and Digest authentication

What must be declared? Realms: A realm is a set of documents, along with a realm name. –Sets of documents that should have the same access rights are declared within a single realm User/Passwords: For each realm, the sets of users and passwords that may access the realm are defined Manner to define the above is web-server specific

Underlying Idea When user requests a resource within a realm (i.e., a restricted resource), he must also send along his user name and password If user name and password are not sent, the web server requests these before returning the resource Exact protocol differs whether Basic or Digest authentication is used

server client (c)Response GET /cgi-bin/checkout?cart=17854 HTTP/1.1 Authorization: Basic YnJpYW4tdG90dHk6T3ch Basic authentication protocol server client (a)Query GET /cgi-bin/checkout?cart=17854 HTTP/1.1 clientserver (d)Success HTTP/ OK … client server (b)Challenge HTTP/ Unauthorized WWW-Authenticate: Basic realm= “ Shopping Cart ” Shopping Cart Username: Password:

HTTP Basic Mechanism When the server gets a request to a protected resource, it checks whether that request has the HTTP header Authorization: Basic username:password If the name and password are accepted by the server (i.e., are those of a user that has the privilege to get the page), then the requested page is returned

HTTP Basic Mechanism If the request does not have the authorization header or the name and password are not accepted, then the server replies with a status code of 401 unauthorized The 401 response will have the header WWW-Authenticate: Basic realm="realm-name" That is, "in order to get this resource, you will have to authenticate using the basic method" –Tells the user to supply authentication for pages in realm-name Browser will automatically open a dialog for the user to enter his username and password

Browser Cooperation Throughout the session, the browser stores the username and password and automatically sends the authorization header in either one of the following cases: –The requested resource is under the directory of the originally authenticated resource –The browser received 401 from the Web server and the WWW-Authenticate header has the same realm as the previous protected resource

Sending the User Name and Password Under Basic authentication, the user name and password are sent as a pair username:password written in the Authentication header The username, password pair are written in Base64. This is not encryption

Declarative Security: BASIC Realm B Realm A /a/A.html /a/B.jsp /b/C.css /b/D.xml E.xsl GET E.xsl OK + Content F.xml

Declarative Security: BASIC Realm B Realm A /a/A.html /a/B.jsp /b/C.css /b/D.xml E.xsl GET /a/B.jsp Basic realm="A" F.xml

Declarative Security: BASIC Realm B Realm A /a/A.html /a/B.jsp /b/C.css /b/D.xml E.xsl GET /a/B.jsp + user:pass OK + Content F.xml

Declarative Security: BASIC Realm B Realm A /a/A.html /a/B.jsp /b/C.css /b/D.xml E.xsl GET /a/A.html + user:pass OK + Content F.xml

Problems with Basic authentication What problems are there with this type of authentication? What type of attack can succeed with this scheme?

Digest Access Scheme The most serious security flaw in the basic scheme is that the name and password are sent unencrypted, and hence everyone on the network path can read it If an attacker snoops a request with basic authentication, she can access to the whole protection space of the resource The digest access authentication scheme solves many of the flaws of the basic schemes, such as the one above

Digest Operation Like the basic, the digest scheme requires that authentication data is sent with each request for a protected resource However, passwords are not sent in clear text The idea is to use a one-way hash, such as MD5 A one-way hash H is a mapping of strings that has the following properties: –It is "easy" to compute H(x), given the input x –It is "hard" to compute x, given the mapping H(x)

Digest Operation (cont) In the digest scheme, instead of sending the password x in clear text, the client sends H(y) –y is the concatenation of the user name, the password, and some additional values (discussed later on) A server that gets digested authentication data repeats the same encryption process and compares its output with the given H(y) –How come server can compute H(y)?

Using Digests for password-obscured authentication server client Internet (a)Request Please give me the internal sales forecast. server client Internet (c)Authorization Please give me the internal sales forecast. My username is “ bri ” My digested password is “ A3F5 ” OK.The digest you sent me matches the digest of my internal password, so here is the document. server Internet client (d)Success digest( “ 0w! ” )=A3F5 ˇ This is a match! server client (b)Challenge You requested a secret financial document.Please tell me your username and password digests. Internet Ask user for username and password digest( “ 0w! ” )=A3F5

Message Digest #5 (MD5) One popular digest function, MD5, converts any arbitrary sequence of bytes, of any length, into a 128-bit digest. –128 bits = 2 128, or about –1,000,000,000,000,000,000,000,000,000,000,00 0,000,000 = possible distinct condensations. Given the result of an MD5 function, do you think you can guess the argument?

MD5 digest examples InputMD5 digest “Hi” C1A5298F939E87E8F962A5 EDFC “bri:0w!” BEAAA0E34EBDB072F8627 C038AB211F8 “ ” 475B977E19ECEE70835BC 6DF46F4F6DE “ C617C0C7D1D05F66F595E 22A4B0EAAA5 “We hold these Truths to be self-evident, that all Men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are life, Liberty and the Pursuit of Happiness-That to secure these Rights, Governments are instituted among Men, deriving their just Powers from the Consent of the Governed, that whenever any Form of Government becomes destructive of these Ends, it is the Right of the People to alter or to abolish it, and to institute new Government, laying its Foundation on such Principles, and organizing its Powers in such Form, as to them shall seem most likely to effect their Safety and Happiness.” 66C4EF58DA7CB956BD042 33FBB64E0A4

Problems, so far What problems do you see with this authentication method so far? Does it really improve the BASIC method?

Digest: More Details In order to avoid a “replay” attack, each time that the client requests a resource –the Server generates a new “nonce” value –Server sends the nonce value as a challenge to the Client –Client computes MD5(user:password:nonce) and sends to Server (actually, there are some more arguments too) –Server verifies correctness Why does this prevent replay attack? –Note: Server must keep track of nonces used in the past

Problems, so far Can someone now impersonate the client? Can someone discover the client’s password? Can someone impersonate the server?

Digest: Even More Details In order to make sure that the server is not compromised –the Client sends with his request a “client nonce value” –The Server returns the resource, along with MD5(user:password:cnonce:resource-content) –Client verifies correctness

The Digest Authentication Handshake Server (1)Server generates nonce (5)Server verifies digest [generate rspauth digest] [generate next nonce] Client WWW-Authenticate (challenge) (2)Server sends realm, nonce, algorithms (3)Choose algorithm from set [generate response digest] [generate client-nonce] (7)Client verifies rspauth digest Authorization (response) (4)Client sends response digest [send algorithm] [send client-nonce] Authentication-Info (info) (6)Server sends next nonce [send client rspauth digest]

Problems, so far Can someone impersonate client? Can someone impersonate server? Can someone see the client’s private data?

Reference RFC 2617,”HTTP Authentication: Basic and Digest Access Authentication”

SSL Connections, HTTPS SSL = Secure Socket Layer

Security on the Internet The Internet is used to transmit sensitive data from clients to servers and vice-versa –User passwords –Credit card numbers –Private client data on remote servers (e.g., Banks) However, data packets are read by several computers on the way from the client to the server (and vice-versa) –Routers, proxies, etc.

Security on the Internet (cont) For secure communication, the following should be provided: –Only the server can read the client requests –Only the client can read the server's responses –Only the client can send requests on behalf of itself –Only the server can send responses on behalf of itself In short, no one should be able to interfere in the interaction, either by reading the transferred data or by impersonating one of the sides

SSL Connections The SSL (Secure Socket Layer) protocol is used to manage security of message transmission on the Internet Data encryption and decryption is based on symmetric and asymmetric keys The HTTPS (HTTP over SSL) protocol is actually the HTTP protocol above SSL transportation

HTTP versus HTTPS HTTP Stateless protocol Non secure connection Non Secure Sockets HTTPS Session-based protocol Secure connection Secure Sockets

TCP/IP SSL SSL in the Network Layers HTTP Protocols

Stages of SSL protocol SSL handshake, server and client: –authenticate each other –negotiate encryption keys and algorithms to be used to establish a joint secret key –Negotiate joint secret key to be used Data exchange –Data is sent between client and server, encrypted with joint private key

Symmetric and Asymmetric Keys Data can be encrypted and decrypted using keys, which are simply large numbers Symmetric keys: the same key is used for both encoding and decoding of the message Asymmetric keys: one key is used to encode the message, and another is used to decode it –Key used to encode = public key –Key used to decode = private key It is considered practically impossible to decode a message without knowing the decoding key

Secure Connection: A Naive Approach Consider the following protocol: –Server and Client send their public keys to each other –Data is encrypted using the public key of the receiver What is wrong with this protocol? –Encryption methods (public keys) are known to everyone - everyone can impersonate the participants –A participant cannot tell whether its received key was indeed sent by the other participant

The SSL Handshake Server hello + SSL settings Client SSL Settings + Certificate Is this a good certificate? 1. Client gets the Server's certificate

The SSL Handshake Server Client 2. Client creates a master secret and shares it with the server

The SSL Handshake Server Client 3. Client and server create symmetric session keys from the master secret

The SSL Handshake Server Client Data is transferred using the session keys (Http Response) (Http Request)

SSL Certificates To assure that the replier to the first request is the server, the server sends a certificate The certificate contains both the server's name and its public key The certificate is issued by a Certificate Authority (CA), which is known to the client in advance –For example: VeriSign, Thawte, RSA Secure Server, etc. CA signs the certificate using a digital signature, which the client can verify

Issuer's Name Public Key Serial Number Validity Period Server's Name The Server's Certificate Issuer's Digital Signature

An Example: The Certificate of bankleumi.co.il

Authentication via SSL If the server needs to assure the client's identity, the first interaction after the SSL handshake will typically be a client authentication Client authentication is done using the regular (e.g., HTTP) authentication mechanisms Why not using a certificate?