1 / 16

Intro to Web

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.

ella-paul
Download Presentation

Intro to Web

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. 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.

  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.

  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.

  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.

  5. HTTP Protocol Request/Response Web ClientWeb 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 is right here.

  6. Basic HTTP Examples - Client Request User-Agent: Mozilla 4.06 Accept: image/gif, image/jpeg, text/plain, text/html, */* Accept-Charset: iso-8859-1,*,utf-8 Connection: Keep-Alive Accept-Language: en GET /myindex.html HTTP/1.0

  7. Basic HTTP Examples - Server Response HTP/1.0 200 OK Server: Netscape-Enterprise/3.5.1 Date: Mon, Jan 1 1998 15:00:00 GMT Content-type: text/html Last-modified: Fri, 1 Dec 1997 12:30:01 GMT Content-length: 1025 Accept-ranges: bytes

  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.

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

  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.

  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.

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

  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.

  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

  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?

  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

More Related