http and tls james walden northern kentucky university

HTTP and TLS

James Walden

Northern Kentucky University

CSC 666: Secure Software Engineering

Topics

1. HTTP

2. Stateless Architecture

3. Proxying and Caching

4. HTTP Vulnerabilities

5. The TLS Protocol

6. Public Key Infrastructure (PKI)

7. Attacks on TLS

8. TLS Defenses (Pinning, HSTS)


HTTP: HyperText Transfer Protocol

Web ServerWeb Client

Request for Resource

Response


Pages Require Many Requests


HTTP GET Request

GET http://www.google.com/ HTTP/1.1Host: www.google.comUser-Agent: Mozilla/5.0 (Windows NT 6.2)

Gecko/20100101 Firefox/35.0Accept: text/html, image/png, */*Accept-Language: en-us,en;q=0.5Cookie: rememberme=true;

PREF=ID=21039ab4bbc49153:FF=4

Method URL Protocol Version

Headers

Blank Line

No Data for GET method


HTTP POST Request

POST http://www.example.com/ HTTP/1.1Host: www.example.comUser-Agent: Mozilla/5.0 (Windows NT 6.2) Gecko/20100101 Firefox/35.0

Accept: text/html, image/png, */*Accept-Language: en-us,en;q=0.5

Method URL Protocol Version

Headers

Blank Line

POST data

name=Jane+Doe&sex=female&color=green&over6feet=true&over200pounds=false&athleticability=NA


HTTP Response

HTTP/1.1 200 OK

Cache-Control: private

Content-Type: text/html

Server: GWS/2.1

Date: Fri, 13 Oct 2006 03:16:30 GMT

<HTML> ... (page data) ... </HTML>

Protocol Version HTTP Response Code

Headers

BlankLine

Web Page Data


Common HTTP Methods

Method Description

GET Retrieve resource located at specified URI.

HEAD Retrieve metadata about resource located at specified URI. Useful for caches to determine if they need to retrieve an updated resource.

PUT Create or replace resource located at specified URI with resource provided by client.

DELETE Delete resource located at specified URI.

OPTIONS Return list of HTTP methods that can be used with specified URI.

POST Create a new resource under the specified URI, e.g. adding a new message in a web forum, adding a comment to a blog post, annotating a photo, etc. In summary, POST is a way for a client to create a new resource without knowing its URI; the client just knows the URI of a “parent” or “factory” resource.


Idempotence and Safety

An operation is safe if making the request will not change any state on the server.

GET, HEAD, and OPTIONS are safe.

An operation is idempotent if making one request has the same effect as making a series of identical requests.

PUT and DELETE are idempotent.

POST is neither safe nor idempotent.

It is possible for servers to misuse requests like GET. Example: GET https://api.deli.icio.us/posts/delete If misused, testing tools, spiders, caches can destroy data.

https://api.deli.icio.us/posts/delete

Common HTTP Response Codes

Response Code Meaning

200 OK Resource is available in the body of the response. No errors.

400 BAD REQUEST

Client sent a request with an error. If there is a response body, it contains an error message.

500 INTERNALSERVER ERROR

Server error. If there is a response body, it contains an error message.

301 MOVED PERMANENTLY

Client triggered action that caused URI to change or attempted to access old URI.

404 NOT FOUND No resource is available at the specified URI.

410 GONE Resource is no longer available at the specified URI.

409 CONFLICT Client requested action that would put resources in an inconsistent state.

http://httpstatus.es/

Common Request Headers

Header Description

Accept: Content-types (Internet media types) acceptable for response.

Authorization: Authentication credentials for HTTP authorization.

Cookie: Sends state previously set by server back to server.

Content-Length:

Length of data in body (important for POST requests.)

Host: Name of server (and port if not default). Mandatory in HTTP/1.1.

If-Modified-Since:

Server should only return a response if the data was modified since date specified in this header.

Referer: URL of web page from which a link was followed to produce this request. Some URLs contain sensitive information, so some sites use intermediate services to anonymize this header.

User-Agent: String that identifies browser, typically containing a product name and version (Firefox/36.0), layout name and version (Gecko/2010), operating system (Linux x86_64), and compatibility (Mozilla/5.0).


Common Response Headers

Header Description

Content-Length:

Specifies length of response body sent to browser except in the case of chunked data, where chunk lengths are sent in body.

Content-Type:

Internet media type of data being sent to browser.

Location: Used in redirection responses.

Server: Server identification string, e.g. Apache/2.4.20.

Set-Cookie: Creation or overwriting of an HTTP cookie.

Transfer-Encoding:

Specifies encoding (compression type or chunked) for page data sent to browser.

WWW-Authenticate:

Specifies type of HTTP authentication that should be used.


HTTP Header Parsing

Handling of duplicate headers. ~50% of browsers/servers will use first header. ~50% of browsers/servers will use last header.

Mixing of protocol versions Difficult to predict effect of mixing of 1.0 and 1.1

headers, especially when headers have the same purpose.

Ex: Expires(1.0) and Cache-Control(1.1) headers.

Semicolon-delimited header values Quoted string format values not handled well by IE. Content-Disposition: attach; filename=“evil.exe;.txt”

Internet Media Types

Standards Original MIME (Multipurpose Internet Mail Extensions) IANA maintains official registry of types at https://

www.iana.org/assignments/media-types/media-types.xhtml

Format Type/Subtype; Optional Parameters Example: text/html; charset=UTF-8

Handling in HTTP Requested in Accept: header. Specified by server in Content-Type: header. Browser may view directly, use plug-in, or start an

external program.

https://www.iana.org/assignments/media-types/media-types.xhtml




HTTP Standards

Historical Standards HTTP 0.9 (1991) 1st documented version. HTTP 1.0 (1996) defined in RFC 1945. HTTP 1.1 (1999) defined in RFC 2616.

Current Standard (well specified HTTP/1.1, 2014) RFC 7230: Message Syntax and Routing RFC 7231: Semantics and Content RFC 7232: Conditional Requests RFC 7233: Range Requests RFC 7234: Caching RFC 7235: Authentication


HTTP/2

Focused on performance; no semantics changes Based on Google’s SPDY protocol. Single TCP connection for each client/server pair. Allows multiple requests and responses to be sent

simultaneously over same connection. HPACK header compression. Server can push additional documents (images,

stylesheets, scripts, iframes).

Status IETF finished, expected to publish RFC in 1Q2015. Firefox 36 and Chrome 40 will support draft HTTP/2.

Uniform Resource Identifiers (URIs)

A URI is a string of characters that identify a web resource that come in two types.

Uniform Resource Names (URNs) Identify a resource by name within a specific

namespace. Ex: urn:isbn:0-395-36341-1

Uniform Resource Locators (URLs) Identify a resource via a representation of its

primary access mechanism, e.g. a network address.

Ex: http://www.nku.edu/


URL Format

<proto>://<user:pw>@<host>:<port>/<path>?<qstr>#<frag> Proto is the network protocol, e.g. http, ftp, mailto, etc. User and pw are optional authentication credentials. Host is the DNS name or IP address of the server. Port is the TCP port number; defaults to 80 for http. Path is the name of the resource on the server, which may or

may not represent a filesystem path. Qstr is a query string typically used by GET requests to send

parameters to an application. Frag is a fragment identifier used by the client to identify a

location within a web page. It is not sent to the server. Some client apps use fragments for navigation, so their contents may be security sensitive.

URL Encoding

<proto>://<user:pw>@<host>:<port>/<path>?<qstr>#<frag> Query string is set of key=value pairs separated by &

- ?q=cloud&lang=en

Whitespace marks end of URL Special characters must be URL-encoded.

- %HH represents character with hex values, e.g. %20 = space.- Special characters include whitespace : @ ? / # &- Any character may be encoded, including proto, path, etc.

URL encoding is also used in the body of POST requests.

http://user:[email protected]:8001/a%20spaced%20path?l=en#section2


HTTP is a stateless protocol

A stateful protocol allows requests to move the server into a different state, in which a request may produce a different result.

Example protocols: FTP, SMTP, TCP FTP command “get rest.txt” will return a different

file when cwd is /public rather than /private.

A stateless protocol treats each request as an independent transaction that is unrelated to any previous request so that communication consists of independent pairs of requests and responses.

Examples: HTTP, IP

Stateless and Stateful Architectures


Handling Statelessness

Store state information directly in the address (URI) To access second page in google search for “http”: https://encrypted.google.com/webhp?

q=http&safe=off&start=10 Works best for web services.

Store state indirectly in an HTTP header (cookies) Most common type of state storage.

Some plug-ins can store state. Flash cookies are the most common type.

HTML 5 provides browser storage features.

Cookies

Maintain state via HTTP headers State specified is set of name=value pairs. Set-Cookie header sent from server. Cookie header sent from browser. No RFC specification used til RFC 6265 in 2011.

Examples Set-Cookie: foo=bar; path=/; expires Fri, 20-Feb-2015

23:59:00 GMT Cookie: foo=bar

Encoding Encode cookies with base64 to avoid metacharacter

interpretation (colons, commas, slashes, quotes, etc.)

Cookie Fields

Expires: if specified, cookie may be saved to disk and persist across sessions. If not, then cookie persists for duration of browser session.

Max-age: similar to Expires, but not supported by IE.

Domain: scoping mechanism to allow cookie to be scoped to domain broader than host that sent Set-Cookie header.

Path: scopes cookie to a specified path prefix.

Secure: prevents cookie from being sent over non-encrypted connections.

HttpOnly: removes ability to read cookie via document.cookie API in JavaScript to protect against XSS.



Cookie Security Policy

Domain parameter limits which servers are sent cookie in complex ways (see table).

Path parameter limits which paths are sent cookies, but JavaScript from any path can read cookies.


More HTTP MethodsMethod Description

COPY Copies file to path in Destination header. Part of WebDAV specification.

MOVE Moves file to path in Destination header. Part of WebDAV specification.

SEARCH Searches directory path for resources.

PROPFIND Retrieves information about resources, such as author, size, content-type.

CONNECT Make non-HTTP connections via HTTP proxies.

TRACE Returns exact request received by header in response body. Can be used to bypass HttpOnly cookie protection against XSS attacks.


HTTP TRACE Example$ telnet localhost 80

Trying... Connected to 127.0.0.1.

Escape character is '^]'.

TRACE / HTTP/1.1

Host: foo

x-myheader: spam

HTTP/1.1 200 OK

Date: Mon, 04 Mar 2009 12:34:45 GMT

Server: Apache/1.3.13 (Unix)

Connection: close

Content-Type: message/http

TRACE / HTTP/1.0

x-myheader: spam

Host: foo

Connection closed.


HTTP Proxies

Browser configured to proxy GET request GET http://www.example.com/ HTTP/1.1 User-Agent: mybrowser/2.0 Host: www.example.com

URL and Host specifications Perform same task. Evolved separately. Proxy must be careful to avoid being tricked into

caching page from one as page from another site

GET http://www.example.com/ HTTP/1.1

Host: www.google.com

http://www.example.com/

http://www.example.com/

HTTP Caching

HTTP/1.1 cache behavior GETs with 200, 301, &c responses may be cached. Cache may be returned to any future requests for that

URL even if headers differ, including cookies. Cache may revalidate content (with If-Modified-Since

header) before reuse but is not required to do so.

Cache-Control header Public: document is cacheable publicly. Private: proxies are not permitted to cache. No-cache: cache but don’t reuse; only FF supports. No-store: do not cache this document at all.

Pragma: no-cache from HTTP/1.0 still in use.


HTTP Headers

HTTP headers can be vulnerable to Injection Attacks, including SQL Injection Cross-Site Scripting (XSS)

Most commonly vulnerable headers Referer User-Agent

String userAgent = request.getHeader(“user-agent”);

String sQuery = “DELETE FROM UP_USER_UA_MAP WHERE USER_ID=“ + userId + “ AND USER_AGENT=‘” + userAgent + “’”

...

stmt.executeUpdate(sQuery);

HTTP Header Injection

Add new header + body content to HTTP response. Client sends input containing end-of-line (EOL) HTTP EOL is CR/LF (\r\n, %0d%0a URL-encoded)

Example Code:

String author = request.getParameter(AUTHOR_PARAM);...Cookie cookie = new Cookie("author", author);cookie.setMaxAge(cookieExpiration);response.addCookie(cookie);

HTTP Response Splitting

Malicious input submitted via AUTHOR_PARAM form input:

A Hacker\r\nHTTP/1.1 200 OK\r\nContent-Type: text/html\r\n<html>Hacker Content</html>

HTTP/1.1 200 OK…Set-Cookie: author=A Hacker

HTTP/1.1 200 OKContent-Type: text/html

<html>Hacker Content</html>

Resulting HTTP responses


Response Splitting Impact

Attacker controls page contents Page defacement. Can redirect to attacker controlled site.

Script executes in context of legitimate site JavaScript sent by attacker as part of second

response has access to cookies and other data of legitimate site.


Cache Poisoning Attack

1. Select a page to poison in proxy cache. Replace /admin with phishing trojan.

2. Locate header injection vulnerability. Inject second response body with trojan.

3. Connect to proxy and send requests.1. First request is header injection described above.2. Second request is for page that’s being poisoned.

4. Proxy talks to app, gets response.5. Proxy interprets 2nd response body as response

to attacker’s 2nd pipelined request. Updates cache with trojan version.


HTTPS (HTTP over SSL)

HTTPS differences Default port is 443. Connection: close HTTP header ends session. RFC 2818: HTTP over TLS

Encrypts URL of requested document HTTP headers HTTP bodies, including response documents All form parameters, as they are either in the URL or

the HTTP body.


Transport Layer Security (TLS)

TLS protocol provides security features for other protocols, such as HTTP, IMAP, etc.

1. Authentication of server to client.

2. Optional authentication of client to server.

3. Confidentiality of communication.

4. Integrity of communication.

TLS 1.0 was published in 1999. SSL 2.0 was first released in 1995 (insecure) TLS 1.2 is most recent, defined in 2008.


TLS Operation


TLS Handshake

Cipher Suites1. Key Exchange Algorithm

Used to exchange session keys for bulk encryption algorithm. Examples: RSA, Diffie-Hellmann, Elliptic Curve Diffie-Hellman

2. Bulk Encryption Algorithm Used to encrypt message stream. Examples: RC4-128, Triple-DES, AES-128, AES-256

3. Message Authentication Code MAC is keyed hash function to ensure integrity. Based on MD5, SHA-1, or SHA-2, key based on master secret.

4. Pseudorandom Function Used to create master secret, a 48-byte secret shared with both

parties. Used to create session keys.

TLS Cipher Suite Example

TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE is the Key Exchange Algorithm RSA for Authentication (digital signatures) AES is the Bulk Encryption Algorithm 128 is the length of the keys CBC is the mode used for the BEA. SHA is the MAC algorithm used for HMAC.

Key Size and SecurityProtection Symmetric Public

KeyDiffie-Hellman

EllipticCurve

Hash

Short term against small organizations

64 816 816 128 128

Very short term against agencies

80 1248 1248 160 160

Short term against agencies (10 years)

96 1776 1776 192 192

Medium term against agencies (20 years)

112 2432 2432 224 224

Long term protection (30 years)

128 3248 3248 256 256

Long term protection with increased defense against quantum computers.

256 15424 15424 512 512

ECRYPT2 recommendations from www.keylength.com


TLS Client Test

Test browser TLS by going to https://www.ssllabs.com/ssltest/viewMyClient.html Does your browser support latest TLS version? Does your browser support weak cipher suites?

Check other clients by going to https://www.ssllabs.com/ssltest/clients.html Are you or your customers using any of the clients

that are missing secure TLS versions and features?

https://www.ssllabs.com/ssltest/viewMyClient.html

https://www.ssllabs.com/ssltest/viewMyClient.html

https://www.ssllabs.com/ssltest/clients.html

https://www.ssllabs.com/ssltest/clients.html


TLS Server Test

Go to https://www.ssllabs.com/ssltest/ Test the following servers

www.nku.edu www.google.com A server of your own choice.

Compare configurations with top servers at https://www.trustworthyinternet.org/ssl-pulse/

Discuss server configurations.

https://www.ssllabs.com/ssltest/



http://www.nku.edu/

http://www.google.com/

X.509 Digital CertificatesCertificate contains

Serial number Identity of issuer, who produced certificate. Identity of subject. Public key of subject. Range of dates for which certificate is valid. Digital signature from issuer.

Signature means that issuer vouches that Public key belongs to subject, e.g. You really are connected to example.com.

Client has list of trusted certificate authorities (CAs) Client will trust certificate if it is signed by one of those CAs or if

issuer has a certificate that was signed by CA.

How Clients Use Certificates

Bulletproof SSL and TLS, Figure 3.1


Abstract Syntax Notation One

ASN.1 is standard for transporting complex data structures over a network in a machine independent manner with multiple coding rules:

BER: Basic Encoding Rules DER: Distinguished Encoding Rules PER: Packed Encoding Rules XER: XML Encoding Rules

X.509 certificates are encoded using PEM PEM (Privacy Enhanced Mail) is Base64 DER DER is subset of BER with only one way to encode. http://lapo.it/asn1js/ will decode certificates.

http://lapo.it/asn1js/

http://lapo.it/asn1js/


View Certificate Exercise

Steps to View1. Pick a HTTPS URL.

2. Click on padlock icon.

3. Select View Certificate or Certificate Info.

Questions4. Who is the owner of the certificate?

5. Who signed the certificate?

6. When does the certificate expire?


Certificate Authorities

CA is an entity that issues digital certificates. Trusted 3rd party that enables public key cryptography. Root CA certificates embedded in browser or OS. Hundreds of CAs exist in dozens of countries.


Obtaining a Certificate

1. Create a public/private key pair. Choose appropriate algorithm and key size.

2. Create Certificate Signing Request (CSR) Contains public key and identity information. Sign CSR with applicant’s private key.

3. Send CSR to CA.

4. CA validates CSR. Checks that applicant matches identity.

5. CA sends certificate to applicant.

Certificate Validation

Domain Validation (DV) certificates are issued based on proof of control over a domain name. Send confirmation e-mail to one of the standard

approved e-mail addresses. If applicant follows link in e-mail, cert is validated.

Organization Validation (OV) certificates require identity and authenticity validation but validation requirements are not consistent.

Extended Validation (EV) certificates are issued with standard identity and authenticity validation procedures documented by the CA/Browser Forum (https://cabforum.org/)


Certificate Revocation

Certificates are revoked when Private key is compromised or no longer in use. Certificate was issued to wrong entity (faulty validation).

Certificate Revocation List (CRL) List of serial numbers of revoked certificates that have

not yet expired. Can be large, so lookup can be slow.

Online Certificate Status Protocol (OCSP) Check revocation status of a single certificate. CA specifies their OCSP servers in issued certificates.


Revocation Problems

Revocation is slow Revocation status data is valid for 10 days.

Revocation is a blacklist technology CRLs were designed as a blacklist. OCSP was implemented as a blacklist, using CRL

data and interpreting no response as not revoked.

Libraries and command line tools don’t check Default configuration is not to check for revocation.

OCSP leaks information about browsing habits Monitor small # of OCSP servers vs entire Internet. OCSP stapling fixes by allowing servers to do OCSP.

PKI Incidents 2001: VeriSign tricked into issuing two code-signing certificates to

someone claiming to represent Microsoft. Certificates not trusted by Windows, but GUI asks user to accept certificate from Microsoft.

2008: Security researcher Mike Zusman obtained certificate for login.live.com by using a personal live.com e-mail address, [email protected].

2008: CertStar (a Comodo branch) is found to issue certificates without any domain name validation. Tester got mozilla.org cert.

2011: Comodo resellers issue certificates for login. yahoo.com, mail.google.com, login.skype.com, etc.

2011: Dutch CA DigiNotar totally compromised; hundreds of certificates issue, including *.*.com and *.*.org. Could not revoke because did not know which certificates issued. Company’s root certificates were revoked and DigitNotar declared bankruptcy.

mailto:[email protected]

PKI WeaknessesDomain owner permission not required

Any CA can issue a certificate for any domain. Do CAs issue certificates for surveillance?

Weak domain validation DV relies on domain ownership information from insecure

WHOIS protocol. Relatively easy to hijack e-mail accounts.

Some CAs have become too big to fail Only small CAs have been removed from root stores.

Revocation is slow and unreliable Revocation status data is valid for 10 days. Browsers interpret no OCSP response as no revocation.

Ivan Ristic’s TLS Threat Model

https://www.ssllabs.com/downloads/SSL_Threat_Model.png


Classic SSL MITM Attack

Browser MITM Server

Client requests TLS connectionAttacker establishes TLS connection with server.

Client receives data fromserver over SSL link with MITM.

Attacker decrypts client requestand forwards to server.

Attacker establishes TLS connection with client usingMITM certificate.

Client requests data via HTTPS

Attacker decrypts server dataand forwards to client.


Browser Certificate Warnings


SSL Stripping MITM Attack

Browser MITM Server

HTTP Request

Attacker rewrites HTTPS to HTTP

Client receives page with onlyHTTP links.

Client clicks on link, sendingsensitive data over HTTPinstead of HTTPS.

Attacker sends sensitive data tosite over HTTPS.


Implementation Issues

Heartbleed (OpenSSL) View server memory (keys, passwords) https://sslimgs.xkcd.com/comics/heartbleed_explanation.png

Goto Fail (Apple)if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)

goto fail;

goto fail;

MS14-066 (Windows) Secure Channel flaw allowed remote code execution.


Renegotiation Attacks

Bulletproof SSL and TLS, Figure 7.1


Side Channel Attacks

Compression Side Channel Attacks CRIME, TIME, BREACH attacks. Insert JavaScript malware into browser. Manipulate data to change compression result, then

observe diffs in compressed encrypted output. Allows recovery of cookies, CSRF tokens.

Lucky 13 Padding Oracle Attack Exploits lack of integrity protection for padding. Insert JavaScript malware into browser. Guess bytes, modify padding to include. 8192 HTTP requests to get 1 byte of plaintext.

Certificate Pinning Clients pin certificates (or public keys) by

Storing certificates for certain hosts, and When connecting to those hosts, validating the certificate sent

by the server by comparing it with the stored certificate instead of by following the digital signature chain via PKI.

Preloaded pins Client developer stores pinned certificate with client software. Valid until certificate expires. Must update app or browser when certificate is replaced.

Uses of Certificate Pinning Browsers preload certificates of their creators and certain widely

used web sites. Mobile apps preload certificates of the sites that they are

associated with.


Dynamic Certificate Pinning Dynamic pinning

Web sites set pins using the HPKP header on a client’s first connection with site.

Valid until max-age header option expires. Secure if first connection with site or first connection with site

after max-age expires not attacked.

HTTP Public Key Pinning (HPKP) header Public-Key-Pins: pin-sha256="base64=="; max-age=expireTime

[; includeSubdomains][; report-uri="reportURI"] Header can include multiple public keys using multiple pin-

sha256 header options. If report-uri field specified, clients should send message to

specified URI if pinned certificate does not match certificate received from server.


HSTS

HTTP Strict Transport Security (HSTS) Sets policy to only use HTTPS with site. All certificate errors are fatal for that site. Protects against MITM attacks including SSLstrip.

Established via HTTP header on 1st connection Strict-Transport-Security: max-age=N; options max-age is number of seconds policy lasts includeSubDomains enforces policy on subdomains

STS Preloaded List in Browsers Well known HSTS sites list stored in browser, so even

1st connection is protected by HSTS for those sites.


HSTS Limitations

Vulnerable to SSLstrip on first connection Or on re-connection after max-age expires. Max-age needs to be long enough that user will

connect to site again before it expires. 1 year is a common max-age setting.

Vulnerable to time manipulation attacks Threat spoofs NTP packets to client to convince client

max-age has expired.

Cookies can be read without includeSubDomains If secure flag is not set on cookie Attacker can use nonexistent subdomain w/o TLS.

Key Points

HTTP Requests (idempotent, safe, and not) Header security issues, including Cookies HTTP response splitting

TLS Security features (C, I, and authentication) Certificates (purpose, validation, revocation) PKI (how it works, weaknesses) Attacks (MITM, implementation, protocol) Defenses (HSTS, certificate pinning)


References

1. David Gourley et. Al., HTTP: The Definitive Guide, O’Reilly, 2002.2. Krishnamurthy et. Al., Key Differences Between HTTP/1.0 and

HTTP/1.1, http://www8.org/w8-papers/5c-protocols/key/key.html.3. Mark Nottingham, RFC 2616 is Dead, https://

www.mnot.net/blog/2014/06/07/rfc2616_is_dead, 2014.4. Dafydd Stuttart and Marcus Pinto, The Web Application Hacker’s

Handbook, 2nd Edition, Wiley, 2011.5. HTTP/2 Home Page, https://http2.github.io/.6. Ivan Ristic, Bulletproof SSL and TLS, Feisty Duck, 2014.7. Sanctum, “HTTP Response Splitting Whitepaper,”

http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf, 2004.

8. Michael Zalewski, The Tangled Web: A Guide to Securing Modern Web Applications, No Starch Press, 2011.

http://www8.org/w8-papers/5c-protocols/key/key.html

http://www8.org/w8-papers/5c-protocols/key/key.html

https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead

https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead

http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf

http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf

http and tls james walden northern kentucky university

Documents

http post request post

resource response csc

http response http1

specified uri

http vulnerabilities

new resource

hsts slide

na slide