- Security Testing Tutorial
- Security Testing - Home
- Security Testing - Overview
- Security Testing - Process
- Security Testing - Malicious Software
- HTTP Protocol Basics
- HTTPS Protocol Basics
- Encoding and Decoding
- Security Testing - Cryptography
- Security Testing - Same Origin Policy
- Security Testing - Cookies
- Hacking Web Applications
- Security Testing - Injection
- Testing Broken Authentication
- Testing Cross Site Scripting
- Insecure Direct Object Reference
- Testing Security Misconfiguration
- Testing Sensitive Data Exposure
- Missing Function Level Access Control
- Cross Site Request Forgery
- Components with Vulnerabilities
- Unvalidated Redirects and Forwards
- Security Testing - Ajax Security
- Testing Security - Web Service
- Security Testing - Buffer Overflows
- Security Testing - Denial of Service
- Testing Malicious File Execution
- Security Testing - Automation Tools
- Security Testing Useful Resources
- Security Testing - Quick Guide
- Security Testing - Useful Resources
- Security Testing - Discussion
Security Testing - HTTP Parameters
HTTP Parameters
We will discuss here a few important HTTP Protocol Parameters and their syntax that are required in constructing the request and response messages while writing HTTP client or server programs. We will cover the complete usage of these parameters in subsequent chapters while explaining the message structure for HTTP requests and responses.
HTTP Version
HTTP uses a <major>.<minor> numbering scheme to indicate versions of the protocol. The version of an HTTP message is indicated by an HTTP-Version field in the first line. Here is the general syntax of specifying HTTP version number −
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
Example
HTTP/1.0 or HTTP/1.1
Uniform Resource Identifiers (URI)
URI is simply formatted, case-insensitive string containing name, location etc. to identify a resource. For example, a website name, a web service etc. A general syntax of URI used for HTTP is as follows −
URI = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
Here, if the port is empty or not given, port 80 is assumed for HTTP and an empty abs_path is equivalent to an abs_path of "/". The characters other than those in the reserved and unsafe sets are equivalent to their ""%" HEX HEX" encoding.
Example
Following three URIs are equivalent −
http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html
Date/Time Formats
All HTTP date/time stamps must be represented in Greenwich Mean Time (GMT), without exception. HTTP applications are allowed to use any of the following three representations of date/time stamps −
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
Character Sets
You use character set to specify the character sets that the client prefers. Multiple character sets can be listed separated by commas. If a value is not specified, the default is US-ASCII.
Example
The following character sets are valid −
US-ASCII or ISO-8859-1 or ISO-8859-7
Content Encodings
Content encoding values indicate that an encoding algorithm is used to encode the content before passing it over the network. Content encodings are primarily used to allow a document to be compressed or otherwise usefully transformed without losing the identity.
All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding and Content-Encoding header fields.
Example
The following are valid encoding schemes −
Accept-encoding: gzip or Accept-encoding: compress or Accept-encoding: deflate
Media Types
HTTP uses Internet Media Types in the Content-Type and Accept header fields in order to provide open and extensible data typing and type negotiation. All the Media-type values are registered with the Internet Assigned Number Authority ((IANA). The following general syntax specifies media type −
media-type = type "/" subtype *( ";" parameter )
The type, subtype, and parameter attribute names are case - insensitive.
Example
Accept: image/gif
Language Tags
HTTP uses language tags within the Accept-Language and Content-Language fields. A language tag is composed of 1 or more parts: A primary language tag and a possibly empty series of subtags −
language-tag = primary-tag *( "-" subtag )
White space is not allowed within the tag and all tags are case-insensitive.
Example
Example tags include −
en, en-US, en-cockney, i-cherokee, x-pig-latin
Where any two-letter primary-tag is an ISO-639 language abbreviation and any two-letter initial subtag is an ISO-3166 country code.
To Continue Learning Please Login
Login with Google