Rise and Hack!: 2015

Thursday, February 12, 2015

Common TCP/IP Protocols

Logical Address:

The internetwork address of a machine.
It is unique universally ( for a local network, universe is the small local network)
It is implemented in software.
IP address is the logical address in TCP/IP protocol suite.

Physical Address:

At physical level, a host or a router is recognized by its Physical address
Physical address is useful only in local network.
It has to be unique locally but doesn't need to be unique universally.
It is usually ( but not always) implemented in HARDWARE.
MAC address is a physical address.

Static Mapping:

To create a table containing the IP to MAC address mapping.
Table is stored on each machine on the network.
Limitation: Physical address of a machine may change for many reasons.
Limitation: Static mapped table has to be updated periodically.

Dynamic Mapping:

Using ARP, RARP to find either the IP or the MAC address of a machine.

ARP (Address Resolution Protocol)

If sender has the local IP address, and needs to know the Physical address to send a packet in local network, it uses ARP protocol.
ARP is used for dynamic mapping.
Maps LOGICAL ADDRESS to PHYSICAL ADDRESS.
ARP packet contains the (IP, MAC) of sender and (IP) of receiver, and is sent to BROADCAST address FF:FF:FF:FF:FF:FF ( all 1s).
All hosts receive the packet but only the intended recipient recognizes the IP address and sends back an ARP Response Packet. The response is UNICAST only to the ENQUIRER.
ARP request is Broadcast & ARP response is UNICAST.

RARP ( Reverse Address resolution Protocol)

Dynamically Maps PHYSICAL address to LOGICAL ADDRESS
When a DISKLESS machine wants to get its OWN LOGICAL address after a reboot, it sends a RARP to BROADCAST FF:FF:FF:FF:FF:FF ( all 1s) address.
Response is sent by the RARP SERVER as UNICAST.
Alternatives to RARP: BOOTP & DHCP ( provides additional info like subnet mask also)
RARP Server does not provide info like subnet mask, which is required by a diskless host.

WHAT IS ARP Spoofing?

ARP spoofing or ARP cache poisoning is a technique by which an attacker sends (spoofed) Address Resolution Protocol (ARP) messages onto a local area network.
The aim is to associate the attacker's MAC address with the IP address of another host, such as the default gateway, causing any traffic meant for that IP address to be sent to the attacker instead.
The attack can only be used on networks that use the Address Resolution Protocol
ARP Spoofing can be used for DoS & MITM attacks.

Prevention?

IP Protocol

Connection-less, Unreliable , best effort delivery service.
Provides addressing and routing capabilities for each data packet.
Used as transmission mechanism by TCP/IP Protocol.
Data is packed in a Datagram
Datagrams can take different routes and arrive out of order.
Datagrams might be duplicated.
Doesn't keep track of route.
Doesn't order the packets.

ICMP: INTERNET CONTROL MESSAGE PROTOCOL

IP protocol lacks the ability to report errors & to check if a particular host is alive.
ICMP compensates for the lack of error control & query facilities in IP protocol.
ICMP is a companion of IP protocol.
ICMP protocol is a Transport layer protocol, but its packets are not directly sent to the Data Link Layer. They are first encapsulated INSIDE an IP datagram.

ICMP Error Reporting

ICMP always reports errors to the original Source ONLY.
ICMP error message will NEVER be responsed with an ICMP error message
ICMP error message is NOT generated for a datagram with MULTICAST Address.
ICMP error message will NOT be generated for a special IP address ( 127.0.0.1, 0.0.0.0)
Destination Unreachable: ICMP message is generated in response to destination(host or protocol or port) unreachable.
Source Quench : ICMP message is generated if there Congestion at the router or destination, slow down babe! (Sender)
Time Exceeded
Parameter Problem ( ambiguity or missing field in datagram)
Redirection: Host's (non-router) routing table is updated statically. A method of updating the routing table is to send the packet to wrong router. It will be redirected to the correct router and an ICMP message will be sent to the host to update its routing table.

ICMP for Diagnostic purposes

Echo-request & echo-reply ICMP messages:

Used to check if the host is able to communicate with the destination host or router.
Used to check if intermediate routers are working.
Used to check if IP protocols on source & destination are working properly.
Echo-request is sent by the Sender.
Echo-reply is sent by the destination.

Time stamp request & time-stamp reply ICMP messages:

Used to calculate the round-trip time between source & destination even if their clocks are not synchronized.

Address mask request & Reply ICMP messages:

Used to find out host's own address mask from a router.
May be used in combination with RARP(to find IP) in case of diskless hosts.

How does Ping work? PING - Packet internet groper command.

Ping is a network utility which can generate a series of ICMP echo-request & echo reply messages to test the reachability of a host.
It also provides statistical information about RoundTrip time by sending its own time stamp in the optional data section of the ICMP echo-request & echo reply message.
Ping program has to be stopped using CTRL+C otherwise it goes on.
Ping prints - TTL, packet loss, number of packets sent, number of packets received etc.
TTL part of the Ping command = number of maximum hops allowed

How does traceroute (UNIX) work

Traceroute is used to trace the route of a packet from source to destination.
Traceroute uses two error messages - TIME EXCEEDED & Destination Unreachable
Traceroute program sends an IP packet using UDP (destined to the wrong port).
The TTL of the IP packet is incrementally set to 1,2,3,4,5 until the destination is reached.
Each router on the path to the destination will decrement the TTL and whenever TTL 0 is reached the router will send back an ICMP "Time Exceeded" error message along with its own IP address.
Traceroute also calculates the round trip time for each of these intermediate routers
In each of these messages the UDP packet is sent to a port that is not supported by UDP. When the packet reaches the destination and TTL=0 it WILL NOT throw a "Time exceeded" error. However, the destination host sends an ICMP "Destination Unreachable" packet, because the port number is wrong. This error message indicates that the destination has been reached.

OSI Model & TCP/IP Model

OSI Model

Application Layer:

This layer includes the Protocols which support an Application. It does not contain the application itself.
When the application needs to send the data across, then it passes the data to the protocols that support it.
Eg: A browser generates an HTTP Request on form submission.
HTTP, SMTP, FTP

Presentation Layer:

Formats the information into a form that everyone will understand.
This layer is concerned with the Syntax and format of Data.
If a browser is used to upload a picture, it will be converted into an HTTP Request and the picture will be represented in a standard format like JPEG, TIFF, GIF, which the receiving side will understand the type of Information contained in the Data.
This layer is responsible for Translation ( System dependent to System Independent format)
This layer is responsible for Encryption or Compression of Information

Session Layer:

Is responsible for establishing/ maintaining/ terminating a session with an Application.
Allows communication between applications in Simplex, Half-Duplex and Full-Duplex forms.
It is also called "port layer"
It manages Application-to-Application Sessions
Example: Images, HTML, CSS files are all stored as separate files on a web server. To download each of them a separate download session is started. The session layer keeps track of which packets and data belong to which file and keeps track of each download session.
The session layer is responsible for session checkpointing and recovery.
Session layer allows information of different streams, to be properly combined or synchronized (Eg - different files being downloaded for loading a single webpage)
In TCP/IP this functionality is handled by application software(browser) addressing a connection to a remote machine and using a different local port number for each connection
AppleTalk Session Protocol, NetBios are Session Layer Protocols.

Transport Layer

Transport Layer ensures delivery from one (Source IP, Port) to Another (Destination IP, Port)
The transport layer ensures that messages/data are delivered without errors, in sequence, and with no data content losses or data content duplications.
Session Layer acts as a manager and manages the multiple files delivered by Transport Layer to be properly combined or synchronized.
TCP & UDP are transport layer protocols.

Network Layer

Responsible for Source IP address to Destination IP address delivery
IP, ICMP, OSPF, BGP, IGMP protocols work at this layer.
Ping operates by sending Internet Control Message Protocol (ICMP) echo request packets to the target host and waiting for an ICMP response. In the process it measures the time from transmission to reception (round-trip time) and records any packet loss. Since PING uses ICMP protocol, it is not associated with any PORT number.
If two systems were connected to the same Link, there would be no need for a Network Layer.
Network layer is needed when, two devices are connected to two different Networks
Network layer provides the routing mechanism for packets.

Data Link Layer:

Responsible for moving a FRAME from one node to the next.
Physical Addressing - Assigns the sender and receiver of the frame.
Flow Control - Rate at which data is absorbed by the receiver
Error Control - Detects and re-transmits damaged or lost frames. Error control is achieved through check-sum added at the end of frame.
Access Control - Determines which node has control of the link at any given time.
ARP, RARP, PPP ( Point to Point Protocol)

Physical Layer:

Moves bits from one hop to the next.
This layer converts bits into voltage for transmission.
This layer controls synchronization, data rate, line noise and medium access.

Wednesday, February 11, 2015

Diffie-Hellman Algorithm - Simple Overview

Diffie-Hellman Algorithm allows two parties to agree on a Shared Secret Key while exchanging messages in Public.

Diffie Hellman is ONLY used for Key-Establishment.

These keys might be used for any purpose depending on the protocol.

Diffie Hellman does not authenticate, so its possible to establish a Secret-Key with a Bad-Guy.

Technical Details

Diffie-Hellman relies on the difficulty of calculating Discrete Logarithms.

p is a Prime Number
g is a Primitive Root of P
(Primitive Root means - p^k mod g will return ALL values from (1, 2 , 3.....p-1) for the first p-1 values of k)
p & g are public and can be intercepted during communication.

Protocol

1. Alice chooses private key "a"

Bob chooses private key "b"

2. A computes a public value A = p^a mod g

B computer a public value B = p^b mod g

3. A and B are exchanged publicly

4. Alice calculates K = B^a mod g = p^ab mod g

Bob calculates K = A^b mod g =p^ab mod g

5. K is the shared secret between Alice & Bob

Alice and Bob can now use K for whatever purpose they want.

Vulnerabilities

An attacker could be doing a man in the middle attack, by establishing two separate keys with Bob & Alice and then being the middleman in their conversation.

Solution: Authenticated Diffie Hellman Exchange.

Encrypt the Diffie-Hellman Exchange communication with a PRE-SHARED SECRET KEY.
Encrypt the Diffie-Hellman Value, with other side's public key.
Sign the Diffie-Hellman Value, with your side's private key.
Transmit a HASH(DiffieHellmanValue, Name, Pre-Shared-Secret) to the other side.

Authentication Protocol Design Concepts

What is Challenge Response mechanism?

Sometimes we need to prove the knowledge of a secret without actually revealing the secret. This is particularly useful when the channel is insecure . Challenge response is a method used to prove the knowledge of a secret key without revealing it.

Protocol Decription: In the scenario where two parties share a secret key.

The two parties exchange random numbers, Ra & Rb.
Each receiving party encrypts the Random number with its Secret key and transmits it back to the sender.
On receiving the encrypted random number, the sender tries to decrypt it with the secret key it knows. If the decryption is successful then sender knows that the other party has knowledge of the secret.

Security Pitfalls: Minor variant of a secure protocol can have security holes.

How would you do an Integrity Check?

There are two methods

Checksum
MAC or HMAC - requires a key

How to design a protocol?

Start with a design, which will most certainly have flaws.
Check for all possible weaknesses and fix them.
So the more we know about types of possible flaws the better it is.

Below is a description of some simple protocols, their weaknesses and possible fixes.

Protocol Flaws associated with Secret Key Based Protocols

1. Protocol: Sending the password in clear text.

Problems: Eavesdropper can intercept to the password during transmission.

Enhancement: Instead send a challenge to the client, the client applies a function on the Shared Secret key and the challenge and sends the value to the server.

Function (Shared Secret, Challenge)

2. Protocol: Only the client side authenticates itself using Function (Shared Secret, Challenge)

Problems:

If an attacker can intercept the communication between client & server, then the attacker can send responses to the client by spoofing the server IP address as it doesn't need to know the secret key shared between the server & client. Attacker can simply retransmit an old challenge to the client.
Attacker can mount an offline password guessing attack, to guess the key assuming he knows the Challenge, Function used, and value of Function (Shared Secret, Challenge)

3. Protocol: After one side authentication, the conversation is sent over clear text

Problems:

Attacker simply hijacks the conversation (after the initial authentication), if he is able to send packets using the server's IP address.

4. Protocol:

Client claims, (I am Alice) to the Sever.
Then server sends an encrypted Random Number, with the Key shared with Alice.
Client decrypts the Random Number and sends it to Server there by proving knowledge of Key.

Problems:

This protocol will require reversible cryptography algorithm to decrypt the Random Number. Hashes cannot be used in this case. Hashes provide performance advantage. Sometimes export issues arise when Encryption is used. Hashing is less likely to have export problems.
If shared key is derived from a Dictionary word, it is vulnerable to dictionary attack.
If the Random Number is recognizable, the attacker can simply claim to be Alice ( I am Alice) and receive an Encrypted challenge, try to decrypt it using dictionary attack. Once a recognizable number ( say 32bit number padded with 32 bit zeros) is generated, the attacker will know the Secret.
If the attacker is eavesdropping (more difficult than claiming to be Alice), then he can read both the Random Number & the encrypted value. He can then try to mount a dictionary attack.

Enhancement: Random Number R is made to have a limited lifetime by concatenating it with a timestamp. This will foil replaying of an old Encrypted Random Number, as the decrypting party will realize that this random number was generated at an earlier time.

5. Protocol: A single handshake is sent to the server, containing the identify claim and an encrypted time-stamp.

I am Alice, Key[timestamp]

Problems:

Requires that client & server have reasonably synchronized clocks (within acceptable clock skew)
An eavesdropper can retransmit I am Alice, Key[timestamp] within acceptable clock skew and impersonate Alice. Enchancement: Server keeps a history of all timestamps sent by Alice, until the acceptable clock skew expires, thus detecting a re-transmission
If Alice, uses the same key for multiple servers, then I am Alice, Key[timestamp] can be re-transmitted to other servers if done within acceptable clock skew. Enchancement: Concatenate the server-name with the timestamp to foil this. I am Alice, Key[ServerBob + timestamp]
If the server is vulnerable to clock resetting attack, then the Attacker may be able to reuse old encrypted time-stamps by resetting the clock on the server. Enchancement: Authenticate based on challenge/response to allow server clock management.

6. Protocol: A single handshake is sent to the server, containing the identify claim and a hash of Secret key & time-stamp.

I am Alice, HASH[SecretKey ,timestamp]

Problems:

If the timestamp is in minutes and the allowed clock skew is 10 minutes, the Server will need to Hash 10 different timestamps to verify the secret key. This might be acceptable.
If timestamp is in milliseconds, trying all timestamps would be unacceptably inefficient.

Enchancement: Send the timestamp along with the identity claim

I am Alice, TimeStamp, HASH[SecretKey,timestamp]

Common Problem with Secret Key Based Protocols

If the attacker gets access to the Database of one of the communicating parties. The attacker may be able to get access to shared secret keys as well as any encrypted timestamps received.

Protocols Flaws Associated with Public Key Based Protocols

1. Protocol:

Client claims, (I am Alice) to the Sever.
Then server sends a Random Number, to the Client (Alice.)
Client SIGNS the Random Number with his Private Key,and sends it to the Server.
Server verifies the Random Number based on Client's Public Key, thereby ensuring that Client knows his Private Key.

Problem:

Attacker, can trick the Client (Alice) into signing something, and use that Signed Value later to forge the Client's Signature. ( If he impersonates the Server's address, waits for Client to connect and then send the quantity as a challenge to the Client)

2. Protocol:

Client claims, (I am Alice) to the Sever.
Then server sends a Random Number, encrypted with the Client's Public Key, to the Client (Alice.)
Client DECRYPTS the Random Number with his Private Key,and sends it to the Server.
Server verifies the Random Number, thereby ensuring that Client knows his Private Key.

Problem:

If the attacker is able to impersonate Server's address, then the Attacker can trick the Client (Alice) into decrypting something that was earlier sent to the Client encrypted with his Public key.

Solutions to Protocol 1 & Protocol 2 Problems:

Issue: Each independently secure protocol scheme, can compromise the security of another if you use same keys for both.

Do not use the same key for two different purposes ( Encryption, Signature). This will prevent an attacker from using one protocol to break another.
Ensure that different uses of the same key are coordinated. Example: If the key is used to encrypt a Challenge and a Message, then add structure to the Quantity by Concatenating a Field before the quantity to identify the type of Field.

What is the reflection Attack?

When mutual authentication is part of a protocol, then each party needs to solve the challenge sent by the other party.

The attacker posing as Alice and attempting to connect to Bob, is able to trick one of the parties to provide an answer to the challenge posed by Bob.

1. Bob provides the solution to Bob's challenge.

Connection 1

Attacker poses as Alice and sends his challenge R1 while trying to connect to Bob.
Bob replies with solution to Attacker's Challenge S1, and sends his own challenge R2 to Attacker.
(Attacker now needs to provide Solution S2 to prove the knowledge of the shared secret)

Connection 2

Attacker poses as Alice and send another challenge R2 while trying to connect to Bob again.
Bob replies with S2 and sends his own challenge R3 to the Attacker.

Now Attacker, goes back to the Connection 1 and uses the solution S2 provided by Bob in Connection 2 and proves knowledge of Bob's shared secret key with Alice. Thus Bob himself got tricked into providing the solution to his own challenge.

2. Alice Provides the solution to Bob's challenge

Connection 1

Attacker poses as Alice and sends his challenge R1 while trying to connect to Bob.
Bob replies with solution to Attacker's Challenge S1, and sends his own challenge R2 to Attacker.
(Attacker now needs to provide Solution S2 to prove the knowledge of the shared secret)

Connection 2

Attacker poses as BOB and send a challenge R2 while trying to connect to Alice.
Alice replies with S2 and sends his own challenge R3 to the Attacker.

Now Attacker, goes back to the Connection 1 and uses the solution S2 provided by ALICE in Connection 2 and proves knowledge of Bob's shared secret key with Alice. Thus Alice got tricked into providing the solution to BOB's challenge.

Solution to Reflection Attack

Have both Bob & Alice do the same thing differently.
Also Initiator should be the first one to prove its Identity.

Use two different keys to Authenticate Bob & Alice. This will require additional storage and configuration.
Challenge from Initiator should be different from the challenge from the responder. Eg : Initiator of the connection can use Even numbers while Responder can use Odd Numbers.

Authentication Protocol Design Flaws CheckList

Consider the following as a list of things when you have to design a new Authentication Protocol.

Lets Assume, Alice is the Client and Initiates the conversation and Bob is the Server.

If an attacker

Shouldn't be able to understand the conversation between Client & Server
Shouldn't be able to do a reflection attack to impersonate either Client or Server
Shouldn't be able to Impersonate by replaying the authentication information to other servers & get authenticated
Shouldn't be able to do an offline password guessing attack to find the Secret Key.
Shouldn't be able to convince the Server that he is Alice.
Shouldn't be able to convince the Client that he is Server.
Shouldn't be able to trick either party into signing or decrypting something.
Shouldn't be able to decrypt old recorded conversations between Client & Server.
Shouldn't be able to Hijack a conversation that was started by either Client or Server, without having one of the parties notice the change.
Modify the messages or replay, rearrange, or reverse the direction of messages.

Monday, February 9, 2015

Server Side HTTP Redirection, SMTP Injection, HTTP Parameter Injection, HTTP Parameter Pollution - Notes

==============================================================================

Server Side HTTP Redirection

==============================================================================

Vulnerability exists when the APPLICATION SERVER uses an Attacker controllable input and incorporates it into a URL and retrieves it using a back-end HTTP Request.

Attacker may use the Application Server as Proxy to connect to a Internal Network resource which are not accessible directly
Attacker may use this to attack 3rd party systems
Attack may connect to other services on the Application Server itself, circumventing Firewall restrictions & exploiting trust relationships.
Attacker can use it to include external Attack Scripts

Attack : If you are able to identify a vulnerable parameter

Try to port scan the internal network using Burp Intruder.
Try to connect to other services on Application Server using 127.0.0.1

==============================================================================

HTTP Parameter Injection

==============================================================================

Vulnerability exists when user supplied "Parameters" are used as "Parameters" to a BackEnd HTTP Request.

Attacker may Inject additional Parameters ( URL encoded ), which are then submitted to the backend service. This might interfere with the application logic.
These additional parameters may not cause any error ( Unlike SOAP Injection)
Attack Requires knowledge of backend parameters or access to Code (Whitebox Testing / 3rd party component)

Example : from=1234&to=54321&amount=1000%26FundsCleared%3DTrue&Submit=submit

==============================================================================

HTTP Parameter POLLUTION ( too many parameters)

==============================================================================

Vulnerability exists because, different web servers behave differently when they receive multiple parameters with the same name. Below are the common behaviors

1. First instance of the parameter is used
2. Last instance of the parameter is used
3. Parameter values are concatenated
4. Parameter values are inserted into an array

Success of Attack depends on how the target server handles multiple parameters

Example

Attacker Submits the following

from=1234&to=54321&amount=1000%26FundsCleared%3DTrue&Submit=submit

After Processing the following is submitted to the back end Service

from=1234&to=54321&amount=1000&FundsCleared=True&FundsCleared=False&Submit=submit

==============================================================================

Attack against RESTstyle URL Rewriting

==============================================================================

When REST Style parameters are used ( where parameters are placed in filepath instead of the query string), the translation processing might be vulnerable to HTTP Parameter Injection & HTTP Parameter Pollution

Example:

/app/user/adam (RESTStyle URL) gets translated to the below URL
app/profile.php?mode=view&user=adam

If the Attacker sets his name as /adam%26mode=edit, then it gets translated to the following

app/profile.php?mode=view&user=adam&mode=edit

The success of attack depends on how multiple parameters are handled by the server.

==============================================================================

Email Header Manipulation

==============================================================================

Some applications offer a facility to email the support staff.
The application sends a SMTP message to the email server.
Vulnerability exists when the message submitted by the user is not filtered or sanitized by the application.
Email functionality allows the sender to submit his emailID, Subject, Message

PHP mail() command

constructs the email and performs the SMTP conversation with mail server
additional_headers parameter specifies the "TO, CC, BCC" by separating each header with a new line.
Sender ID: abc@gmail.com%0ABcc:all@website.com

==============================================================================

SMTP Command Injection

==============================================================================
When the application itself performs the SMTP Conversation, it is possible to Inject SMTP Commands.

SMTP client issues "DATA" command and then sends the Message Headers & Body.
To finish the message, a single DOT (.) is sent after a new line (CRLF)

SMTP INJECTION

Text in Red is the Injected content.
Injected content is URL-Encoded and Injected in the Subject Header.
This constructs two email messages
Email message ends with a DOT after a NEW LINE.

MAIL FROM: abc@gmail.com

RCPT TO: support@gmail.com

DATA

From: abc@gmail.com

To:   support@site.com

Subject: Feedback

Site is not working

MAIL FROM: abc@attacker.com

RCPT TO: all@site.com

DATA

From: abc@attacker.com

To:   all@site.com

Subject: ATTACK

This is an Attack

Preventing an SMTP Injection

1. Email message should be checked against, regular expressions

2. Subject should not contain new Line

3. Length of Subject should be Limited

4. Alternatively, provide hardcoded subject messages

5. Lines containing a single dot should be disallowed.

==============================================================================

Sunday, February 8, 2015

XML Injection, SOAP Injection - Notes

==============================================================================

XML Injection

==============================================================================
XML is used extensively in web applications

In Request & Responses to submit data & receive data from server.
In Messages between back-end components
AJAX mostly uses XML for communication with server.
Browser extension components also use XML to communicate with server.
Content type: text/xml

XML EXTERNAL ENTITY ATTACK ( XXE Injection )

Entity Reference:

Characters with special meaning in XML like "<" will generate an error as it is interpreted as the start of a new element.
To avoid errors, replace the "<" character with an entity reference (<)
Entity references always begin with an ampersand (&) and end with a semicolon (;)
For < , > the corresponding entities are < >
XML allows CUSTOM ENTITIES to be defined at the start of XML document itself using DOCTYPE element.
<!DOCTYPE note [ <!ENTITY testreference "referencevalue"> ]>
&testreference; will be replaced by referencevalue

Vulnerability exists because

XML parsing libraries support the use of ENTITY REFERENCES.
XML allows the use of EXTERNAL REFERENCES, whose values are fetched dynamically
EXTERNAL ENTITY definitions use the URL Format & can refer to web URLs or local file.
If the XML response contains an "External defined ENTITY", THEN the contents of specified URL or FILE are RETRIEVED & INCLUDED in the response.

ATTACKER simply specifies an external entity in his XML Request by adding or modifying DOCTYPE element.

SYSTEM keyword is used to specify an EXTERNAL ENTITY
URL may use also the file: protocol
<!DOCTYPE note [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<!DOCTYPE note [ <!ENTITY xxe SYSTEM "http://www.foo.com/hack.txt"> ]>
<foo> &xxe; </foo>
The contents of the file will replace &xxe;

Consequences of XXE

Attacker can use application as proxy to access external server as well as Internal resources and services
Attacker can test for open ports on backend systems.
Attacker can cause a DoS attack, by reading a file stream indefinitely.

==============================================================================

SOAP ( Simple Object Access Protocol) INJECTION

==============================================================================

SOAP INTRODUCTION

Web Service uses two methods to exchange data

1. SOAP (Simple Object Access Protocol)
2. REST (Representational State Transfer)

SOAP uses HTTP protocol to transmit messages
SOAP uses XML to represent the data (Content-Type: application / soap+xml)
Using user-supplied-data in SOAP messages can lead to vulnerabilities.
Directly exposed web-services are worthy of vulnerability examination
WSDL (Web Services Description Language) file describes the following

-How to call the web service
-What parameters it expects
-What data structure it returns

Tools for testing WEB Service Testing - SoapUI

Web Service ( on the Left )

SOAP Request (on the Right)

SOAP INJECTION VULNERABILITY

Vulnerability occurs because SOAP uses XML, and XML is an Interpreted Language.
If the ATTACKER is able to inject METACHARACTERS like < > and / in a SOAP messages, then it can interfere with application's logic.

Injecting an additional <FundsCleared> True </FundsCleared>, in a bank application

It may allow funds to be transferred even if there are no funds
This Attack depends on how the application processes multiple elements with same TAG
Inject has to be done in a way that preserves the XML Syntax

Preventing SOAP Injection

Implement BOUNDARY VALIDATION filters

Filter at Application Boundary- when data is received from the USER
Filter at SOAP service Boundary -, after the input data has been generated, or extracted from DB or processed from user supplied Input.

HTML Encode XML Metacharacters like < > / etc.

Attacking SOAP Service

To test if vulnerability exists >>>> Try inserting </foo> in each parameter, if you get an error, then input is being used in a SOAP service.

SOAP Injection Vulnerability is difficult to detect
SOAP Injection Vulnerability is harder to exploit as it needs knowledge of XML Structure, a verbose error message might help in this case. Else its pure guesswork.

Example ATTACK

Expected Request Format

</Transfer>

After Injection (Injected content in RED)

<Amount> 1000 </Amount>

<FundsCleared>True </FundsCleared>

<Amount> 1000 </Amount>

</Transfer>

Request After getting processed by the application
(works if the application process the FIRST <FundsCleared> Tag it encounters)

<Amount> 1000 </Amount>

<FundsCleared>True </FundsCleared>

<Amount> 1000 </Amount>

<FundsCleared>False</FundsCleared>

</Transfer>

The Injected content Can include comments to comment out a part of the XML Request


<Amount> 1000 </Amount>

<FundsCleared>True </FundsCleared>

<!--Amount> 1000 </Amount>

<To> --><To>54321</To>

</Transfer>

==============================================================================

Saturday, February 7, 2015

OS Command Injection, Path Traversal & Local File Inclusion Vulnerability - Notes

When data is passed from one component to another

Data considered "Safe" by one component may NOT be Safe for an Onward component

Attacker may pass crafted input which may be interpreted as commands in an Onward component

Onward component may have much more functionality, than what the application component uses.

Attacker can exploit this additional functionality

==============================================================================

OS Command Injection

==============================================================================

Vulnerability exists when >>> User supplied input is passed to system shell.
Attacker supplies crafted input, which is passed as parameter to shell functions like system() or exec()
Commands are executed with the Privilege of the vulnerable "Application"
Commonly found in ADMIN interface of an - Application Server, firewall, router, printer

Crafted Input usually contains Shell Meta-characters

Pipe Character "|" redirects output from one process to input of another.
Pipe Character "|" can be used for chaining multiple commands
Semicolon ";" is a command separator.
Ampersand "&" is used as command separator to batch multiple commands
Command1 & Command 2 , second commands runs regardless of success of first
Commands1 && Command2 , second command runs only when first is successful
Command1 || Command 2, second commands runs only when second fails
Placing a command between BackTicks Eg. `command` causes the Shell to execute it and replace the `command` with the results of this command.
Command1 (`command2`) will evaluate to Command1 (resultofcommand2)

Checking for OS Command Injection Vulnerability
Most reliable way is to execute a function which causes a time delay.

|| ping - i 30 127.0.0.1 ||
|| ping - n 30 127.0.0.1 ||
Try all the MetaCharacters | ` & ; %0A || &&

If time delay occurs then application may be vulnerable to command Injection

If you are not able to retrieve the results of your command, you have two options

Output the results into \wwwroot\output.txt file and use browser to view it
Use TFTP to copy tools up to the server, then use telnet to create a reverse shell and Use mail command to send output to yourself via SMTP

Prevention of OS Command Injection Vulnerability

1. Avoid calling OS commands directly

For a web application, Built-in APIs are a very good alternative to OS Commands.
Built-in API cannot be manipulated to perform tasks other than those it is intended to do.

2. If use of OS commands is unavoidable,

WhiteList approach should be used. Allow only alphabets and numbers.
Meta-characters and white-spaces should be rejected.
Additionally, use Command API like "Runtime.exec" in Java & "Process.Start" in ASP.NET which launch a specific process via (name, command line parameters) instead of directly passing the input to a shell interpreter.

Note: Command APIs like - Runtime.exec tokenizes the input into an array of words, then executes the first word in the array as command with the rest of the words as parameters. The risk in using "Runtime.exec" depends on the command being used in source code. If "cmd" is used as command, then there this poses risk of OS Command Injection. Another risk associated with Runtime.exec is that of the user entering an unintended parameter.

3. Applications should use minimum privilege accounts or use multiple low privilege accounts.

Following functions are exploited to carryout OS command Injection

PHP - exec, eval, passthru, proc_open, shell_exec, system, backtick operator (`)
C/C++ - system, execlp, execvp, ShellExecute, _wsystem
JAVA - Runtime.exec
==============================================================================

Path Traversal Vulnerability

==============================================================================

Vulnerability exists when user-controllable data is used to access files & directories in an unsafe manner.
Attacker supplies crafted input which may allow him unintended read or write access to files.

Consequences/Risk : May allow an attacker to read or overwrite sensitive files

Password files for OS and Application
Server and Application Configuration files
Include files containing database credentials
MySQL database files or XML files
Source code files
Log files containing usernames or session tokens

If you get write access then, it can ultimately be used for arbitrary command execution.

Create scripts in startup folder
Write script in web directory & execute by calling in browser

Preventing Path Traversal Vulnerability

Most effective Technique

Avoid passing user submitted data to filesystem API.
Files which do not need to be access controlled can be placed in webroot & accessed via URL.

If it is unavoidable to take filename as a parameter then

Maintain a mapping of fileName to fileID
Allow files to be accessed using FileID only. There is no attack surface in technique.

In case where file upload & download functionality is required & user needs to specify the filename. Take all the following steps

Perform decoding & canonicalization of user input.
Check if the filename contains backslash (\), forwardslash(/) , null bytes, if yes, then stop processing
Hard code the list of permissible filetypes and reject any request for a different file type.
Now, use file system API (Eg. getCanonicalPath) to verify that, the file PATH specified is actually the same as the PATH allowed by the application, and only then allow access to the file.
Java - Java.io.File.getCanonicalPath ,
ASP.NET - System.io.Path.GetFullPath

Use a chrooted environment to mitigate the impact of path traversal vulnerabilites

Chrooted directory - is treated as filesystem root
Any attempt to access a directory above it using /../ sequence is ignored.
On Windows - mount a directory as new logical drive & access it using the associated drive letter. It will not allow access to higher directories using /../ sequence.

Identifying Path Traversal attack targets in an application

1. Initial mapping of the application helps in identifying Path traversal attack targets

2. Thoroughly test the functionality where User can

upload or download files
share documents
upload images
download ebooks, documents, manuals

3. Test any GET or POST request PARAMETER which contains a filename or directory name

4. Test application functions which may retrieve data from a server filesystem ( instead of DB)

displaying documents
displaying images

5. If you have local access to the application server (Whitebox test)

Use a tool like FileMon (Win), ltrace/strace (Unix) to moniter file system activity
Using Burp Intruder, inject a UNIQUE STRING into every user injectable parameter in the application.
Detect the UNIQUE string injected above using a filesystem moniter tool & Identify the parameter and test it for Path Traversal Vulnerability

Detecting the existence of Path Traversal vulnerability

1. Test whether user supplied crafted input is being blocked by the application

Try the following two as filenames

foo.txt

/bar/../foo.txt

If Application behave in the same way for both inputs, then, it MAY BE VULNERABLE

Point to be Noted: Most file systems attempt canonicalization of a filepath before they try to retrieve it, In the above case /bar/../ cancels out ( folder /bar/ doesn't need to exist

2. To TEST If the application is vulnerable & allows READ ACCESS try the following

../../../../../../../../../../../etc/passwd
../../../../../../../../../../../windows/win.ini

3. To TEST CONCLUSIVELY, that the application is vulnerable & allows WRITE ACCESS

Write into a file that any user can write into & then write into a file in which even root cannot write The difference in application response can be USED TO CONCLUDE THAT writing is successful

Try the following in WINDOWS

../../../../../../../../../../../test.txt

../../../../../../../../../../../windows/system32/config/test ( will fail)

Try the following in UNIX

../../../../../../../../../../../tmp/test.txt

../../../../../../../../../../../tmp (will fail)

Point to be Noted: Overwriting a directory with a file will always fail in UNIX
Point to be Noted: All file systems ignore redundant /../ sequences, so try submitting a large number of traversal sequences,
Point to be Noted: Windows tolerates both forward and backward slashes as directory separators.
Point to be Noted: Unix only accepts forward slashes as directory separators.
Point to be Noted: Don't rely on the knowledge of OS of the app server, a backend service may be using a different OS, so try both back and forward slashes.

4. Alternative method, to TEST if WRITE ACCESS is working is to try and write a new file in webroot & open it with browser.

Circumventing Flawed Defense mechanisms

If the mechanism used to prevent Path Traversal is flawed ==> it can be bypassed

1. If the filter attempts to sanitize the input to remove the sequences, it can be defeated with Encoding

2. Try both back & forward slashes, some filters only remove forward slash while file system may support both. Try the following encodings for /../

URL encoding
16 bit Unicode encoding
Double URL Encoding
Overlong UTF-8 Unicode Encoding
Use Burp Intruder to generate "Illegal Unicode" within Burp, these may be accepted by the Unicode decoders, particularly on windows.

3. If application removes ../ but doesn't remove it RECURSIVELY from ( ....//), then the following will work because ../ will get removed and ../ will be left behind.

....//
....\/
....\\
..../\

4. If filetype (suffix) is being verified by the application, Sometimes, it can be subverted by placing a null byte as follows

../../../../boot.ini.jpg

Point to be Noted: This works because, this check is done in a Managed Environment (Java) which allows Strings to have a NULL character, but the API actually retrieves the file in an UNMANGED environment, in which Strings are NULL Terminated.

5. If application appends the filetype suffix on its own, then also NULL byte attack can work

6. If an application tries to verify that that the filename starts with a particular directory name (downloads), then it can be subverted as follows

downloads/../../../../../../../etc/passwd

==============================================================================

File Inclusion Vulnerability ( Local & Remote)

==============================================================================

File Inclusion: Some scripting languages ( like PHP) support the use of Include functions ( include() in PHP). The content of included file is interpreted as if the code was actually copied and pasted.

Remote File Inclusion Vulnerability

PHP's include function accepts REMOTE file path, and thus is a basis of numerous vulnerabilities.
Vulnerability exists when >> User controllable input is used to specify the INCLUDE file name.
Attacker can specify an external URL pointing to a malicious script as the location of the include file.

www.example.com/index.php?Country=US

The corresponding backend PHP code is

$country =$_GET['Country']include ( $country. '.php' );

The contents of US.php are effectively copied in index.php and then are executed.

Local File Inclusion Vulnerability

When the include function of any language allows local (or only local -Eg. Server.Execute() in ASP) files to be included, and the application accepts User controllable data as input to the Include function then the attacker may be able to specify a local file ( Eg. /Admin.aspx) and have it included in the page.

Attacking File Inclusion Vulnerabilities

Commonly found in request parameters which specify Language or Location
Found in parameters which specify a server file name.

To Detect a remote file inclusion vulnerability

Find the Parameter to be tested & Specify the URL to a server you control and see if your server gets any requests from the vulnerable application

To Detect a local file inclusion vulnerability

Wider range of scripting environments allow Local File inclusion compared to remote file inclusion
Submit the name of a known executable or static resource and check if it is included in the response

Mitigation: A safe solution is to use a Switch/Case statement to determine which file to include.

==============================================================================

Thursday, February 5, 2015

Session Management & Access Control - Notes

Session Management Functionality

Used to uniquely identify a Given User Across multiple requests
Used to handle the "State Data" associated with a given user's session
Helps persist the assurance of a given user's identity beyond the authentication step.

Consequence of Attacks on Session Management

Attacker can assume the identity of another user without knowledge of their credentials
Assume identity of admin & own the application.

Why do we need State?

HTTP is a stateless protocol.
HTTP has No mechanism to link a series of requests to a particular user.
Business Applications need a mechanism to keep track of requests coming from the same user.
State information can Include - client IP address, User-Agent, e-mail, username, user ID, role, privilege level, access rights, language preferences, account ID, current state, last login, session timeouts, and other internal session details.

How do we maintain State?
Three mechanisms exist

Sessions are used to maintain state.
HTTP Authentication can be used to maintain State

The credentials are submitted along with each request in HTTP Headers

Basic, Digest, NTLM mechanism

Sessionless State mechanisms

State data is stored on client

State data is stored in a hidden form field or cookie.

State data stored on the client must be protected, so it is encrypted or signed.

State data should include sufficient context in order to prevent an attacker from replaying it later.

Vulnerabilities in Session Management Mechanism fall in two groups

Weakness in the generation of tokens
Weakness in handling sessions tokens

Token Generation Weaknesses

Concerns related to weak tokens apply to

Password recovery tokens sent to Email
CSRF tokens
One time access tokens
Tokens used for "Remember Me" functionality
Tokens allowing "Unauthenticated Customer" to see the "Order Status"

1. Meaningful Tokens are weak

Tokens generated using transformation of user-related data

Are weak
Exhibit Structure & are often separated by delimiter.
Can be broken down into SubParts & Analyzed
Subparts can be analyzed for meaning & their function

Attack:

Such tokens are commonly encoded using XOR, Base64, Hex, ASCII.

Try decoding various decodings to Unpack the token

Not all components of a structured token may be processed by the application

--Narrow down on useful components of a token to reduce entropy & complexity.

User "Char frobber" payload type in Burp Intruder to modify a token one character at a time.

2. Predictable Tokens can be guessed

Predictable tokens

do not contain meaningful data
but can be guessed ( might involve trial & error)
a sample of tokens can be used to generate other valid tokens

Predictable token are generated using

hidden pattern (hidden using encoding)
time dependency - time is used as input to token generation algorithm
Weak Random number generator. - sample of tokens can be used to find the sequence of tokens that the algorithm will generate next

Securing Session Management

Generate STRONG Tokens

1. To Generate strong tokens

Use an extremely large set of possible values
Use a strong source of pseudo-randomness, to ensure unpredictability.

2. Token should have no Meaning or Structure ( not even hidden or obfuscated structure)

3. Source of randomness should be chosen carefully

Java.util.Random - can be extrapolated both forward & backward given a single output.
Java.util.Random - should not be used

4. Use only those algorithms which are "Explicitly" described as "Cryptographically Secure"

5. Along with chosen source of Randomness, Include the following as a source of entropy

Source IP
User-Agent
Time of request in Milliseconds

6. Above sources of entropy will mitigate any weakness in the PRNG

7. Highly Effective Formula to generate a token

HASH (PseudoRandom Number + User-Specific Data + Secret String ( generated fresh on reboot))

Protect Tokens Throughout Their Life Cycle

Tokens should only be transmitted over HTTPS
Prevent Brute force - Length of token should be at least 128 BITS ( 16 BYTES)
Entropy - Avoid Birthday attack - Session ID must provide 64 bits of entropy. Entropy is estimated to be Half of the length of the session ID. So 128 BITS is a good length.
We can generate Cryptographically strong session ID using HASH Functions.
Cookies should use the "Secure" cookie attribute
Application must not accept any cookies submitted through "URL".
Use HTTPS throughout the application, including static pages (help & Images)
Do not offer public unencrypted contents and private encrypted contents from the same host, instead use two different hosts, such as www.example.com over HTTP and secure.example.com over HTTPS for sensitive contents (where sessions exist). The former host only has port TCP/80 open, while the latter only has port TCP/443 open.
Avoid HTTP to HTTPS redirection on the home page (using a 30x HTTP response), as it can be used by an attacker to gather (or fix) a valid session ID.
The session ID must be renewed after any privilege level change within the associated user session. Ex- from anonymous user state to the authenticated state, password changes, permission change, regular user role to an administrator
If multiple cookies are set for a given session, we must verify all cookies (and enforce relationships between them) before allowing access to the user session.
Use client side JavaScript code to capture web browser tab or window close event and close the current session before closing the web browser, emulating a logout.
Bind the session ID to client IP address, User-Agent, or client-based digital certificate. If a change or anomaly is detected change or anomaly in the middle of an established session, this indicates session manipulation and hijacking attempts.
Limit Cookies using cookie scope, and avoid submitting tokens for accessing static resources
Never transmit token in URL as it gets logged
Cookies disabled ? - Use post request for navigation & store token in hidden form field
Logout should be implemented
Logout should invalidate the session token & dispose all session related data
Session Expiration should be implemented ( keep it small 10-30 mins)
Session Expiration should invalidate the token & dispose all session related data
Concurrent logins should be prevented
A new token should be issued at login, everytime.
HelpDesk should not get to see the User-Session-Tokens
Domain & Path of "Session Cookies" should be set as Restrictively as possible
Arbitrary & Unrecognized tokens submitted by users should not be accepted.
Fresh session should be created after "successful authentication" to mitigate session fixation

Session Fixation AttackVulnerability exists when - application does not assign a new session ID after Successful Login
Attack : 1. Attack obtains a valid session by connecting to the application2. Making a user authenticate with that session ID

Set the sessionID in the URL

Set the sessionID in hidden form field

Set the sessionID in cookie, using XSS vulnerability (:P)

3. Then hijacking the validated session

18. In case where an application handles sensitive credit card data, without authentication
Ex: Shopping without logging in

Keep the checkout page sequence really small & generate a new session at first page of this small checkout process.
Use per page tokens, to be safe from an attacker who knows the token used on first page of the checkout process, from accessing user data.
Personal data should be masked & not completely shown back to the user.

Cookie Domain Restrictions

Some sub-domains of a given domain may have a lower level or trust, so sensitive cookies should be restricted from being submitted to these sub-domains.

Cookie "domain" ignores both the "Protocol" & "Port", so an application with same domain, but a different Protocol or Port will have access to the cookies.

Cookie is set by "foo.bar.com" & "domain" attribute is NOT set.

Cookie is submitted to "foo.bar.com"
Cookie is submitted to all sub-domains like "admin.foo.bar.com"
Cookie is NOT submitted to the parent domain - "bar.com"
Make sure any subdomain is not unsafe

Cookie is set by "foo.bar.com" & "domain = foo.bar.com"

Cookie is submitted to "foo.bar.com"
Cookie is submitted to all sub-domains like "admin.foo.bar.com"
Cookie is NOT submitted to the parent domain - "bar.com"
Make sure the sub-domains are not unsafe.

Cookie is set by "nuclear.facility.com" & "domain=facility.com"

Cookie is submitted to "nuclear.facility.com"
Cookie is submitted to all sub-domains like "admin.nuclear.facility.com"
Cookie is submitted to the parent domain - "facility.com"
Cookie is ALSO submitted to all sub-domains of parent domain "unsafeapp.facility.com"

Cookie Path Restrictions

Application at path /app/secure/a/b/index.jsp sets a cookie

Browser will by default submit the cookie to /app/secure/a/b/ & its sub-directories
Browser will NOT submit the cookie to the parent directory

When path is set to "/app/" by the application at /app/secure/a/b/index.jsp

Then cookie is submitted to all sub-directories of /app/

However,

Path based security mechanism are ineffective, because it is stricter than same-origin-policy
Its easy to obtain a cookie scoped to a different path
A malicious path may open a window targeting a different path of same domain & can read & write to that window without restrictions, because same-origin-policy allows this

Per Page Tokens

A new token is created along with each user request (is stored in cookie or Hidden form)
Fine-grain control over sessions is achieved
Both main session token & per-page token are validated with each request
Online banks uses-per page tokens for increased security

Benefits of per page tokens

Prevents session fixation attacks
will block a hijacked session after a single request is made by both attacker & user
Can be used to track the user's movement through the application.
Can block attempts to access a functionality out of a defined sequence.

Reactive Session Termination

Used by online banks
terminate session every time user submits anomalous request
can slow down the probing of application by many orders of magnitude.

Friday, January 30, 2015

Web Application Technologies - Security Interview Preparation Notes

HTTP Protocol

was originally meant for retrieving static text based resources
has been extended in various ways to support complex applications
is a REQUEST-RESPONSE protocol
is a STATELESS protocol
uses STATEFUL TCP protocol for the transport mechanism, but HTTP itself is STATELESS

HTTP Messages (Both request & Response)

Both Requests and Responses have

One or more headers ( each on a separate line)
A MANDATORY blank line (CRLF)
An OPTIONAL body.

HTTP Requests

First line of HTTP request always contains the following three items , separated by spaces

1. Method - GET - GET does not allow a message body, since it is used for requests

- POST
2. Path & query string - path is the location of the resource
- query string is to pass parameters to the resource
- query string is followed by "?"
3. Protocol - HTTP 1.0
- HTTP 1.1 - In this version the "HOST" header is mandatory

Other Headers in a Request

1. Referer - URL from which request originated

- the header was misspelled originally and has retained the wrong spelling

2. User-Agent -info about the software that generated the request

-MOZILLA is used as a prefix for historical reasons, to assert that the requesting browser is compatible with the "Netscape" standard.

3. HOST - specifies the hostname as the "path" in first line does not usually contain the hostname

HTTP Response

First line of HTTP response always contains the following three items, separated by spaces

1. HTTP Version - HTTP 1.0

- HTTP 1.1

2. Status code - 200 (numeric code)

3. Status Description - OK ( textual description of Status code)

Other Interesting Headers in HTTP Response

1. Server - Info about the Web Server and installed modules and OS

- Info may not be accurate

2. Set-Cookie - a further cookie , that is, a cookie to be included in future requests

3. Pragma - a response header

- directs not to store the response in cache

4. Expires - to indicates that the response content expiry date

- a date in the past means response should not be cached

What is the difference between "No-Cache" & "No-Store"

No-Cache

Response is stored in the cache, but the response should not be reused for subsequent requests without first re-validation with the server using

if-Modified-Since,
If-Unmodified-Since,
If-Match,
If-None-Match .

No-Store

Instructs to make a best effort not to write the response to disk (i.e not to cache it).
Provides no guarantee that it will not be written to disk.
If sent in a request, a cache MUST NOT store any part of either this request or any response to it.
If sent in a response, a cache MUST NOT store any part of either this response or the request that elicited it. This directive applies to both non-shared and shared caches.

Provides no guarantee that it will not be written to disk.

Reason is - the HTTP/1.1 definition makes a distinction between history stores and caches.

If the user navigates back to a previous page a browser may still show you a page that has been stored on disk in the history store

What is the difference between Pragma & Cache-Control?

The "Pragma" header field allows backwards compatibility with HTTP/1.0 caches.
Cache-Control was not defined until HTTP/1.1
HTTP /1.0 clients do not understand "Cache-Control" header
When the Cache-Control header field is also present and understood in a request, Pragma is ignored.
Cache-Control header takes precedence in case of HTTP/1.1 ==> Pragma is ignored when both "Cache-Control" and "Pragma" are present.
When the "Cache-Control" header field is not present in a request, caches MUST consider the "No-cache" request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present.
When sending a no-cache request, a client ought to include both the Pragma and cache-control directives in order to target both HTTP 1.0 and HTTP 1.1 caches

Example
GET / HTTP/1.1
Host: www.example.com
Cache-Control: max-age=30
Pragma: no-cache

This will constrain HTTP/1.1 caches to serve a response no older than 30 seconds, while precluding HTTP /1.0 clients from serving a cached response.

What is the Difference between GET & POST methods?

GET Method

Designed to retrieve resources
Can be used to send parameters in the query string of the URL
GET requests can be bookmarked and reused later.
"GET-Request-URL" is displayed on screen
GET requests get logged in browser history & Web Server's access log
GET requests can be cached, if "no-store" directive is not present.
"GET-Request-URL" is also sent to other sites in "Referer" header.
GET Requests should NOT BE USED to transmit sensitive information.
The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match
GET Request has Length Restrictions ( 2048 characters)
GET Request does not have a BODY
Only ASCII encoding is allowed ( Encoding type: application/x-www-form-urlencoded)
Hitting "Back Button" will simply resubmit the GET Request

POST Method

Designed to perform "Actions".
Parameters can be submitted using both the URL Query String as well as using Message Body Parameters submitted using the Message Body ( not the Query String) will not be logged on Server or in Browser History.
Hitting Back button will alert the user that the Data will be resubmitted and ask for confirmation.
POST Request cannot be bookmarked (POST request URL can still be Bookmarked)
No restrictions on type of data, even Binary is allowed (multipart/form-data)
No length restrictions

Other HTTP Methods

HEAD

Returns the HEAD of the Response to corresponding GET Request
Aim is to check if the resource exists on the server
Server's response = (Response to a GET request) MINUS (The body)
Server returns the same headers as it would for a GET Request

TRACE

Used for diagnostics
Server returns the exact "REQUEST" message it received.
Used to detect the effect of Proxy servers that manipulate the request

OPTIONS

Returns the list of Methods supported for a particular Resource
Response contains "Allow" Header
Eg. Allow : GET, POST , PUT, DELETE, OPTIONS

PUT

Attempts to upload the specified resource to the server
Content to be uploaded is in the Request Body
Can be used to attack the Application.

URLs

scheme://domain:port/path?query_string#fragment_id
SCHEME is mostly the protocol ( but not always)
PORT is OPTIONAL
PORT is used when it differs from the Default Port used by the Protocol
PATH is specified using /a/b/c/ and is OPTIONAL
QUERY STRING starts with "?"
QUERY STRING contains "name=value" pairs separated by Ampersand (&)
FRAGMENT ID starts with "#", but "#" is not a part of the Fragment ID
FRAGMENT ID identifies a portion of the document
FRAGMENT ID is not sent to the server along with the GET Request
FRAGMENT ID is processed fully on the client side

REST - Representational State Transfer

A style of Architecture meant for distributed systems
In REST "Requests & Responses" both contain "Representation of the State" of the system (Example: HTTP)
World wide web (HTTP Protocol, URL format) conforms to REST Architecture
REST- URL is a UNIQUE identifier for the resource being accessed.
The HTTP Methods (GET, POST, PUT, DELETE) describe the operations to be performed on the resource addressed by the Unique URL.

REST-style URL

URL containing its parameters within the URL file path rather than the Query String
http://example.com/search?os=android&model=nexus4
[Above is a Normal URL, though it is still conforms to REST]
http://example.com/search/android/nexus4
[REST style URL]

HTTP Headers

CONNECTION

Whether to keep the TCP connection open or close it

CONTENT ENCODING

Type of encoding (Gzip) used in to compress the Response Body

CONTENT LENGTH

Length of Message Body.
In case of "HEAD" Method, Content Length tells the length of corresponding GET Method

CONTENT TYPE

Type of content contained in message body (text/html)

TRANSFER ENCODING

Chunked
Transfer-Encoding HTTP header in used in place of the Content-Length header
Senders can begin transmitting dynamically-generated content before knowing the total size of that content.

ACCEPT

Types of CONTENT (image, docs) the client is willing to accept

ACCEPT ENCODING

Types of content encoding the client is willing to accept.

AUTHORIZATION

Used to submit the credentials for one of the HTTP Authentication types

HOST

Specifies the name of the host that appears in URL being requested

IF-MODIFIED-SINCE

To check if the resource has changed since the last request, if not, then server may allow use of Cached copy.
Response code 304 will mean => Use the cached copy

IF-NONE-MATCH

Specifies an Entity tag ( a string identifier)
Client submits the Etag along with request
Etag is used to identify the version of resource.
If client "Etag" from client matches current version => Response code 304
Response code 304 will mean => Use the cached copy

ORIGIN Header ( Used in Cross Origin Requests)

Used in cross domain requests to indicate the domain (only the domain name) from which request originated

Referer Header

Gives the complete URL from which request originated

Response Headers

Access-Control-Allow-Origin

Part of HTTP CORS (Cross site request Standard)
Indicates the sites from which a resource can be accessed via XMLHTTPRequest (AJAX)
Earlier, HTTP Requests generated by Scripts could only be sent to the origin domain.

Cache Control

Passes caching directives

See above for difference between "Cache control" and "Pragma"

Etag

Specifies an entity Tag (is received in a Response)
Is used to track the version of the resource
Is sent back to server using "If-None-Match" header
If Etag of a resource is the same, then a cached copy can be used

Expires

Server the duration for which the resource can be cached, using this header.

Location

Used in Redirection Responses (Responses with 3xx Status code)
Identifies the location of the Redirect

WWW-Authenticate

Sent along with a 401 (Not authorized) response
Provides the details of types of authentication the server supports
Client sends the authorization values using "Authentication" Header

X-Frame-Options

Used to protect against ClickJacking
Declares a policy (communicated from server to client browser)
Declares whether the client browser may display that response in an <IFRAME> which is part of other web-pages
Values: DENY, SAMEORIGIN, ALLOW-FROM

Cookies

Are Data Values stored on client, by the server
Are sent to server along with every request
Can be used to exploit vulnerabilities
Are name-value pairs, the value of cookie, does not contain "spaces"
Cookie is set using "Set-Cookie" Header
Multiple cookies require multiple "Set-Cookie" Headers

"Set Cookie Header" can have following OPTIONAL ATTRIBUTES

Expires: The date until which cookie is valid.
Expires: Future Expiry => cookie is stored in persistent storage, and is reused later browser sessions,
Expires: If not set => the cookie is only valid for current browser session.
Domain: The domain for which cookie is valid
Domain: Must be same as or subdomain of parent domain
Path: URL Path for which cookie is valid
Secure: Cookie is transmitted over HTTPS Only
HTTPONLY: Cookie cannot be accessed by Client Side Javascript (For XSS Prevention)

HSTS : HTTP STRICT TRANSPORT SECURITY

An opt-in Security Enhancement
Specified by a web application using "Strict-Transport-Security" Response Header
Once this Header is received, then all future communication is sent on HTTPS
Strict-Transport-Security: max-age=31536000; includeSubDomains
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Max-Age: applicable for duration
includeSubDomains: all subdomains should be served on HTTPS
preload: Site owners can sign-up to get their domain on HSTS Preload list maintained by Major browsers

Status Codes

1xx : Informational

2xx: Successful ( 200 OK)

3xx: Redirection related

4xx: Error of some Kind

5xx: Server Error of some kind

100 CONTINUE

Initial Request: Client sends Header - "Expect: 100-continue" , To determine if server is willing to accept a request (based on the request headers) before the client sends the body, to check the legitimacy of the Request (Example : POST)
Server Responds with 100 CONTINUE or else 417 EXPECTATION FAILED

200 OK

Request is Successful

301 Moved Permanently ( Redirect Related)

Redirect THIS and ALL FUTURE requests to a URL specified by the "Location Header" in Response

302 Found (Redirect Related)

Temporary Redirect to a URL Specified in "Location Header"

304 Not Modified ( Redirect Related)

Instructs to use the cached copy stored on client

400 Bad Request

Invalid Request (Probably malformed)

401 Unauthorized

Server requires HTTP Authentication
Server response will contain - "WWW-Authenticate header"
"WWW-Authenticate" Header will give details of supported authentication types

403 Forbidden

No one is allowed to access this resource, regardless of authentication

404 Not Found

Resource does not exist

405 Method Not Allowed

Method Used (Eg. PUT, DELETE) is not supported by specified URL

413 Request Entity is Too Large

The "Request" sent is too large to Handle

414 Request URI Too Long

Request URL is too long

500 Internal Server Error

Server Encountered an error
May be because of an unexpected Input caused unhandled error
See server's full response for details

503 Service Unavailable

Server is working, but the backend application is not working
Try to identify if one of your actions caused this.

What is HTTPS? - HTTP Secure

HTTP uses TCP as its transport mechanism
HTTP is unencrypted and can be intercepted
HTTPS is essentially HTTP tunneled over SSL.
SSL protects Confidentiality & Integrity of underlying HTTP Traffic
HTTPS Prevents eavesdropping & MITM Attacks
HTTPS also provides Authentication of the Website & WebServer
A site must be Entirely hosted over HTTPS
Partially loading some of the content (Scripts & CSS) on HTTP, makes the user vulnerable to attacks.
Cookies on an HTTPS site should have "Secure" Flag Set
SSL uses long-term public and secret keys to generate a short term session key to encrypt the data flow between client and server

A in CIA = Availability ( not Authentication)

HTTP Authentication

HTTP Protocol has its own mechanism to authenticate users. This is mostly used over Intranet only

Basic

credentials are sent in base64 encoded string
credentials are sent with each request
Should only be used over HTTPS

NTLM

Uses a challenge/response mechanism to avoid password capture or replay attacks

Digest

credentials are sent as MD5 hash
HASH is calculated using a NONCE & Password
NONCE is used to avoid replay attacks

Web Application Technologies

Web Applications use multiple technologies to delivery their functionality.
To be able to attack a Web application, understand how various components work together.
Understand the weakness of each component

Server Side Functionality

Server serves both static & dynamic resources.
Dynamic resources - Generated by scripts,
Scripts - take input and give an output
Input is in the form of parameters
Parameters allows the scripts to tailor the output to the individual user.

Parameters are sent to the application in following ways

URL Query String
REST-Style URL's file path
HTTP Cookies
Request Body (POST method)

Additionally

Any part of HTTP Request can be used as an Input for processing Eg - User-Agent

Technologies Used on Server Side

Scripting Languages ( PHP, Perl )
Application Platform (Java, ASP.NET)
Web Server - IIS, Apache
Database - MYSQL, MS-SQL, Oracle
Other Backend Components - SOAP-based Web Service, Directory Service

Source of many web vulnerabilities

Application Design
Third party packages

Some commonly Used Technologies

1. Java Platform ( Application Platform)

WAS de-facto for large scale enterprise applications

Long history & widely adopted = > Many high quality dev tools, app servers & frameworks available

Can be run on several OSes

Important Terms

Enterprise Java Bean ( EJB )

A heavyweight software component
Encapsulates a business function or logic
Intended to handle concerns like - persistence, transactional Integrity & Security

Plain Old Java Object (POJO)

An ordinary Java Object
POJO refers to User defined Objects
Much simpler than EJB
Lightweight compared to EJB

Java Servlet

An Object that resides on an application Server
Processes HTTP Requests & HTTP Responses

WEB Container

An engine which provides run-time environment for Java-based web applications
Example : Apache Tomcat, WebLogic, JBoss

Java is well suited for modular approach. Many open source, third party components exist to help reduce development time

Examples

Authentication Module - JAAS, ACEGI
Presentation Layer - SiteMesh, Tapestry
Database Object Relational Mapping - Hibernate
Logging - Log4J

To attack: Identify the component being used, download it and try to find a vulnerability in the component and use it to attack the application.

2. PHP

Personal Home Page
Highly powerful and rich framework for web applications
Used in conjugation with other technologies
Ex: LAMP ( Linux, Apache, My SQL, PHP)

Many Open Source components exist for

Bulletin Boards: PHPBB, PHP-Nuke
Admin Front Ends: PHPMyAdmin
Webmail: SquirrelMail, IlohaMail
Photo galleries: Gallery
Shopping Carts: osCommerce, ECW-Shop
Wikis- MediaWiki, WakkaWikki

Design & default config of PHP framework makes it easy to unintentionally introduce security bugs

PHP Platform itself have several bugs

These bugs can be used to attack PHP Application

3. XML (Extensible Markup Language)

Specification to encode "DATA" in both human & Machine readable form.
XML document contains - DATA & MARKUP
Extensible means - XML allows arbitrary tags & attribute names
Data Type Definition (DTD) - Information contained in XML Document, which describes the Tags and attributes used in the XML Document.
XML is used extensively in web applications

Web Services

Web application Vulnerabilities are equally applicable to Web Services
A web service is a "method of communication" which allows two software systems to exchange DATA over Internet
Service Requester - requests the data
Service Provider - processes request & provides the data
Service provider & Requester often use different programming language
Web Service is thus a "Method to exchange Data".
Web Service uses two methods to exchange data

1. SOAP (Simple Object Access Protocol)
2. REST (Representational State Transfer)

SOAP uses HTTP protocol to transmit messages
SOAP uses XML to represent the data (Content-Type: application / soap+xml)
Using user-supplied-data in SOAP messages can lead to vulnerabilities.
Directly exposed web-services are worthy of vulnerability examination
WSDL (Web Services Description Language) file describes the following

-How to call the web service
-What parameters it expects
-What data structure it returns

Tools for testing WEB Service Testing - SoapUI

Web Service ( on the Left )

SOAP Request (on the Right)

What is the difference between SOAP Web Service & REST Web Service ? ( Interview Question)

RESTful Web Services

is faster compared to SOAP Web Services
using REST for a Web Service is a recent trend
does NOT NECESSARILY have to use XML
Easy & Lightweight to use RESTful Web Service
RESTful Web Service is STATELESS
provides CACHING over HTTP GET method ( improves efficiency)
has no standard set of Rules to describe the Web Service Interface.
Client should already know what to expect from the web-service
Resource is accessed using a UNIQUE URL
Easy to Integrate with Existing websites
has a small learning curve compared to REST

SOAP based Web Services

uses XML to fetch the DATA.
provides WSDL to specify the interface of the web-service
allows a mechanism to describe the web-service and advertise its existence.
useful for complex operations and those which require maintenance of STATE.
SOAP supports multiple protocols ( REST mostly uses HTTP)
SOAP has a bigger learning curve

Client Side Functionality ( Small Notes )

Document Object Model (DOM)

A programming interface for HTML documents.
Can be used to QUERY the HTML document & MODIFY it through API.
can access HTML elements by ID.
can traverse the HTML document.
can be used to Read & Update Cookies.
is Manipulated by AJAX to dynamically updated the page.

AJAX ( Asynchronous Javascript and XML)

used to avoid full page reload
performs an "in the background" HTTP Request & updates the page
"XMLHttpRequest" object is used to make AJAX requests
Allows arbitrary content to be sent ( not only XML)
uses Synchronous method when it makes sense to make the user wait for the response
increases the attack surface & has historically introduced some vulnerabilities.

What is Same Origin Policy ?

Security policy implemented by browsers
DISALLOWS content coming from one origin from accessing content coming from another origin.
defines ORIGIN as = Protocol + host + port ( all three should match)
-- A subdomain is considered a different host

Subtle Points of Same origin policy

A page on domain A can send a request to domain B, but cannot process the response within the context of domain A.
page from domain A can load a script from domain B and execute it within the context of domain B
page on domain A cannot modify the cookies or other DOM data of domain B

Encoding Schemes

URL Encoding

To safely transport characters over HTTP
URLs can have only printable ASCII characters
Prefix % followed by "ASCII code expressed in Hexadecimal"
%25 = %
%0D = Carriage Return
%0A = New Line
= Null Byte
+ = Space
%20 = Space

To attack: URL encode "space" ? % & ; + # if you submit them as data

Unicode Encoding

Supports all the world's writing systems
it is a 16 bit encoding scheme
Prefix is "%u" Suffix is hexadecimal of the character "Unicode"

UTF-8

Variable length encoding
uses one or more bytes to represent each character
each byte of the UTF-8 is encoded and Prefixed with %
Eg: %e2%89%a0 is a single character

HTML Encoding

to represent "metacharacters" as "content" within HTML document
< &lt
> &gt
Any character can be HTML encoded as follows
&#65 (Notice, the additional #)