16
Intro to Web Started as a simple means to publish scientific information between people.(CERN/Switzerland) Used a new concept, Hypertext. This concept had text with markups that defined relationships between this document and other documents, to make cross references easier. Documents also had simple markups to allow for a nicer presentation of their data. (Lists, etc..) This got somewhat out of hand.

Intro to Web

Embed Size (px)

DESCRIPTION

Intro to Web. Started as a simple means to publish scientific information between people.(CERN/Switzerland) Used a new concept, Hypertext . This concept had text with markups that defined relationships between this document and other documents, to make cross references easier. - PowerPoint PPT Presentation

Citation preview

Page 1: Intro to Web

1

Intro to Web Started as a simple means to publish scientific

information between people.(CERN/Switzerland) Used a new concept, Hypertext. This concept had text with markups that defined

relationships between this document and other documents, to make cross references easier.

Documents also had simple markups to allow for a nicer presentation of their data. (Lists, etc..)

… This got somewhat out of hand.

Page 2: Intro to Web

2

Web Evolution People enjoyed the ease of use of

navigating marked up documents, and being able to click on links to other sources of information (Mosaic), but wanted more.. New markups to perform new actions were added.. Background images.. Progressive Images.. Tables & Frames.. And then the most concerning issue of all.

Executable code was added to web pages.

Page 3: Intro to Web

3

Client/Server Relationship Designed with the concept of a client/server

relationship. The client would request a starting page, and continue from there. Each document would have a unique resource identity, called a URL, or Uniform/Universal Resource Locator.

Given the starting idea of a web of documents, the connection between the client and server was built as a very simple identification of document information, so the server knew what to do. The only information the client needed to know was the URL, which contained the Protocol, Host, Port, and Resource Reference.

Page 4: Intro to Web

4

HTTP Protocol Intro HTTP originally had two parts, a Single Request

and a Single Response. With the request information the client had the capability to send additional information that would be useful when processing the request. For example, as browsers started to diverge on HTML support, the variable User-Agent: started to be sent to web server with a request. This allowed a web server to try and send content more useful for that type of user.

This lead to privacy problems as well, when browsers got over ambitious. Browsers started to send email addresses and other information just to be helpful.

Page 5: Intro to Web

5

HTTP Protocol Request/Response

Web Client Web Server

www.umbc.edu, please give me /index.html

Sure, that file exists. It is 12871 bytes long,a MIME type of text/html, and the data isright here.

Page 6: Intro to Web

6

Basic HTTP Examples - Client Request

User-Agent: Mozilla 4.06Accept: image/gif, image/jpeg, text/plain,

text/html, */*Accept-Charset: iso-8859-1,*,utf-8Connection: Keep-AliveAccept-Language: enGET /myindex.html HTTP/1.0

Page 7: Intro to Web

7

Basic HTTP Examples - Server Response

HTP/1.0 200 OKServer: Netscape-Enterprise/3.5.1Date: Mon, Jan 1 1998 15:00:00 GMTContent-type: text/htmlLast-modified: Fri, 1 Dec 1997 12:30:01 GMTContent-length: 1025Accept-ranges: bytes

Page 8: Intro to Web

8

HTTP Protocol Problems Transport Security

– As we know, the transport is a straight connection over a TCP/IP channel. This connection has nothing special associated with it, and therefore is unencrypted. For reading basic data, this is fine. For sensitive data, this is a problem, as it may be sniffed off the network.

Authentication– Client to Server

» The HTTP protocol allows for HTTP-level authentication. This is done using a request header to send an encoded username and password with the request. This is just a simple Base64 encoding.

Page 9: Intro to Web

9

HTTP Protocol Problems (continued) Authentication (continued)

– Server to Client» Also, given the standard TCP/IP connection, there is no real

way to verify that the server who answered the request is the real server that the client asked for. For example, if somebody tricks a client into thinking the name www.umbc.edu points to a different address, users may be tricked into releasing private or personal information.

Stateless– Difficult to track requests from point to point. For

simply browsing pages, this is not a problem. If the user needs to interact with the system in any manner, this becomes essential. (Shopping Cart, etc..)

Page 10: Intro to Web

10

HTTP Protocol Enhancements Secure Data Transport (SHTTP, HTTPS)

– Security was added to the HTTP exchange with SHTTP, and then HTTPS. This was the addition of SSL (Secure Sockets Layer) around the HTTP protocol, which added not only a secure transport, but the ability of a client to view the information about a server. (View the Server X.509 Certificate)

Note: This does not increase the security of other points in the chain. If the server is trivial to compromise, then the data can still be easily disclosed. Nobody has tried to steal data by decrypting SSL data, but people attack web servers all the time.

Page 11: Intro to Web

11

Web Cache Control Directives One problem that emerged was the caching

of sensitive data as users moved around a site. As users and companies move through common web data caches, this was an issue. Now server have the ability to return that the data should never be cached by the web proxy, or that it should have a short lifetime.

This obviously depends on the proxy following these directives. Many do, many do not.

Page 12: Intro to Web

12

Browser Enhancements Cookie Support

– In an attempt to solve the user tracking problem, browsers added “Cookies”. A Cookie is simply a bit of data that is returned to the web server with a request for data. For example, a web server may issue a cookie that will be returned whenever a user hits a page within “/myapplication/*”. The cookie is not executable, and does not have any more data when it returns, as it did when it was created. (Starting to be misused, however.)

Page 13: Intro to Web

13

Scripting Languages Browsers added scripting and executable

code to their pages, to help reduce the client to server interactions, as well as to provide more responsive and dynamic environments for users. Under Netscape, this was JavaScript, and under IE this was VBScript. (Both now adhere to ECMA Script, which is a variant of JavaScript.) Scripting has introduced a variety of security problems over time, but these will be addressed in the section on mobile code.

Page 14: Intro to Web

14

Client Side Certificates To address the weak state of affairs in client

side authentication, Netscape added the ability for users to have a digital certificate that would cryptographically prove their identity. This certificate was a public/private key pair, and allowed a user to submit the certificate to a web site as proof of their identity. Their certificate would be issued by a known authority, and therefore recognizable as valid.

Issues:– Key Revocation– Key Management

Page 15: Intro to Web

15

Web Security Issues, Now? At this point, we have several things

(assuming the client browser allows and supports it):– The ability to establish an encrypted connection.– The ability to cryptographically authenticate

both ends of the connection.– The ability to track a user from page to page, to

maintain session information So now what?

Page 16: Intro to Web

16

Web Server Security General Problem List

– Maintaining Server Security– General Network Security– More advanced interactions with browsers

» Java or other client-side application information exchanges

– Application Security» Trusted User Input» Buffer Overflows» Weak handling of authentication

URL arguments FORM hidden data