In deze les krijg je de basics van software quality te zien. Vooral HTTP requests en headers.

Downloads

Powerpoint
Lab 1
Installation of postman

Lesvideo:

Aantekeningen

Disclaimer

  • You understand that in this class we may cover methods to exploit vulnerabilities in contemporary computer systems and computer networks.
  • You further understand that we may learn techniques employed by unethical individuals to circumvent security mechanisms, violate copyright, cause damage, cause financial loss, or break the law in other ways.
  • You hereby pledge to use all information obtained in this class in an ethical and responsible manner, properly observing University Policy and the law.
  • You further pledge to abide by course rules, in particular (but not limited to) hacking systems declared off-limits by the instructional staff.
  • By using the course materials, you accept that you will only lawfully use it in a test lab – with devices that you own or are allowed to conduct penetration tests on – to enhance your own knowledge. We do not endorse use of any information expressed on the course outside of a lab environment.
  • Any actions and or activities related to the materials contained in this course is solely your responsibility. The misuse of the knowledge and information in this course can result in criminal charges brought against the persons in question.

Introduction

Three specifications are central to the Web:

  1. URL (Uniform Resource Locators) / URI (Uniform Resource Identifiers)
  2. HTML (HyperText Markup Language)
  3. HTTP (Hypertext Transfer Protocol)

HTTP

http scheme

Client-server model: client-server model Note: This goes for HTTP/1.*, HTTP/2 works slightly different

Requests and responses
HTTP is lineoriented, just like many other internet protecols. Communication takes place using strings of characters, separated by carriage return (ASCII 13) and line feed (ASCII 10).

GET request: get request

Response: response

GET vs POST request: POST requests should be used when the action about to be taken has side effects on the server, i.e. when something is permanently changed.

  • With GET, a client asks for information.
  • With POST, the client contributes information.
  • With GET requests, the browser is free to resend the request, for example, when the user presses the “back button” in his browser (not suitable for money transfers in a bank).
  • POST requests, on the other hand, cannot be reissued by the browser without first asking the user for permission to do so.
  • In a GET request, any parameters are encoded as part of the URL.
  • In a POST request, the parameters are “hidden”.

POST request example: post request The parameters are encoded as you are used to, but they are hidden in the request rather than being part of the URL.

URL Encoding refers to the escaping of certain characters by encoding them using a percent sign followed by two hexadecimal digits. Example: AT&T –> AT%26T

Security concern

  • As all requests originate on the client-side, that is, on computers of which the user has full control, nothing stops the attacker from replacing the browser with something completely different.
  • Everybody can write a program to connect a socket and do the actual protocol conversation for him/her.

Proxy: proxies let you change headers and data before they are passed to the server

Referer header
A Referer header is sent by most browsers on most requests. The header contains the URL of the document from which the request originated.

  1. It leaks information to remote sites. Any part of the URL, including parameters, will be visible to the third-party web server and any proxies that handle the request.
  2. The Referer header originates on the client. Some web sites check this header to make sure the request originated from a page generated by them (e.g. to prevent attackers from saving web pages, modifying forms, and posting them off their own computer). This security mechanism will fail, as the attacker will be able to modify the Referer header to look like it came from the original site.

Caching
Caching refers to temporarily storing documents close to the final destination, in order to reduce download times.

  • Local cache: is managed by the browser itself. When the browser requests a document from a remote server, it often stores a copy on the disk or in memory.
  • Shared (proxy) cache: is typically a server in the local area network. If one user reads an on-line newspaper, and another user reads the same paper shortly after, the proxy cache may serve a local copy of the document to the second user.

Some documents should not be cached.

  • Visitors a stock information website most likely want up to date stock information, not yesterday’s news.
  • People might be able to use the back button to see other people’s web pages in a shared browser, such as in Banks, Internet cafés.

Such sites need a way to tell browsers and proxies that documents should not be cached, or that they may only be cached for a limited time. As with most other control information on the web, cache control is handled by HTTP headers.

Cookies
With cookies, the web server asks the client to remember a small piece of information. This information is passed back by the client on each subsequent request to the same server.

HTTP headers are used for both setting and returning cookies. When server wants the client to remember a cookie, it passes a Set-Cookie header in the reply: set-cookie

Cookies are returned using the Cookie header: cookie header

Drawbacks:

  • Firstly, cookies may be limited in size, so space consuming states cannot be safely represented using cookies.
  • Secondly, cookies are handled on the client-side, so we have to keep making sure that a misbehaving user doesn’t change the state to his own liking.

Sessions

Sessions are server-side collections of variables that make up the state.

The session ID uniquely identifies one session object on the server, the session object “owned” by the client making the request.

Session hijacking
Many web sites use a session-based log-in, in which a session is initiated once the user has given a valid user name and password.

The attacker would not need to know the password of the victim, as the session ID works as a “short-time password” or a proof of successful authentication after a user has logged in.

How would the attacker gain access to the session ID?

  • Guess it,
  • Calculate it,
  • Brute-force it,
  • Find it by trial and error
  • Cross-site Scripting
  • Use referer header
  • Packet sniffing
  • …

Countermeasure: The secrecy of the session ID is the only mechanism that gives real protection.

Secondary measures:

  1. Tie the session ID to the IP address of the client.
  2. Tie the session ID to certain HTTP headers passed by the client, such as the User-Agent header.
  3. Have variable session IDs, a scheme in which the session ID is changed for every request.

HTTPS

To make a web server secure, encryption plays an important role. In a web setting, encryption usually means HTTPS.

  • HTTPS may be described as HTTP communicated over an encrypted channel.
  • The encrypted channel can be provided by the following protocols:
    • Secure Socket Layer (SSL)
    • Transport Layer Security (TLS)

Encryption only protects the network connection between the client and the server. An attacker may still attack both the server and the client, but he will have a hard time attacking the communication channel between them.

Packet sniffing
Packet sniffing attacks the network transport rather than the application or the client.

HTTPS makes it impossible for someone to listen to traffic in order to extract secrets. People may still sniff packets, but the packets contain seemingly random data. packet sniffing

Man in the middle (MITM)
In MITM, the attacker fools the victim’s computer into connecting to him rather than the real server (e.g. a bank). The attacker then connects to the target server on behalf of the victim, and effectively sits between the communicating parties, passing messages back and forth.

He may thus both listen to and modify the communication.

man in the middle

When HTTPS is used, the clients will always verify the server’s certificate. Due to the way certificates are generated, the man in the middle will not be able to create a fake, but valid certificate for the web site.

HTTPS provides good protection of the communication channel, unless:

  • The user neglects the warnings from the browser.
  • The browser allows the user to neglect its warnings.
  • The user falls for cheap domain name or protocol tricks played by an attacker.
  • The CA may be tricked into giving out false certificates.
  • The browser vendor trusts a CA that the user wouldn’t trust.
  • The browser (or server) has a buggy SSL/TLS implementation.
  • The user’s computer is controlled by an attacker.