By Poonam chauhan

A9 M.E.(I.T)

 Transport

layer How protection is provided in Transport layer What is insufficient transport layer protection Impact of insufficient transport layer protection How do attackers attack How to prevent

The transport layer is the fourth layer of the OSI reference model. Function of Transport layer:

Transport layer accepts data from session layer breaks it into packets and delivers these packets to the network layer. It provides an end-to-end dialog that is the transport layer at the source device directly communicates with transport layer at destination device. It is responsible for the determination of the type of service that is to be provided to the upper layer. Normally it transmits packets in the same order in which they are sent and also facilitate the transmission of isolated messages.

It is responsible for the determination of the type of service that is to be provided to the upper layer. Normally it transmits packets in the same order in which they are sent however it can also facilitate the transmission of isolated messages.

A site is secure means that there is the presence of transport layer protection. HTTPS, SSL and TLS are essential staples of website security. Without this assurance we have no confidence of who were talking to and if our communications both the data we send and the data we receive is authentic and has not been eavesdropped on.

SSL is Secure Sockets Layer which is the term we used to use to describe the cryptographic protocol used for communicating over the web. SSL provides an asymmetric encryption scheme which both client and server can use to encrypt and then decrypt messages sent in either direction.

Transport Layer Security and the successor to SSL. Youll frequently see TLS version numbers alongside SSL equivalent; TLS 1.0 is SSL 3.1, TLS 1.1 is SSL 3.2, etc. These days, youll usually see secure connections expressed as TLS versions:

HTTPS is Hypertext Transport Protocol Secure and is the implementation of TLS over HTTP. HTTPS is also the URI scheme of website addresses implementing SSL, that is its the prefix of an address such as https://www.americanexpress.com and implies the site will be loaded over an encrypted connection with a certificate that can usually be inspected in the browser.

Unfortunately we often find sites lacking and failing to implement proper transport layer protection. This is because of the perceived costs of implementation, sometimes its not knowing how and sometimes its simply not understanding the risk that unencrypted communication poses and sometimes not configured properly

Definition: Applications frequently fail to authenticate, encrypt, and protect the confidentiality and integrity of sensitive network traffic. When they do, they sometimes support weak algorithms, use expired or invalid certificates, or do not use them correctly.

Insufficient Transport Layer Protection Insufficient transport layer protection allows communication to be exposed to un-trusted third-parties, providing an attack vector to compromise a web application and/or steal sensitive information. However, unless the website is configured to use SSL/TLS ,configured to use SSL/TLS properly, the website may be vulnerable to traffic interception and modification.

Lack of Transport Layer Encryption When the transport layer is not encrypted, all communication between the website and client is sent in clear-text which leaves it open to interception, injection and redirection (also known as a man-in-the-middle/MITM attack). An attacker may passively intercept the communication, giving them access to any sensitive data that is being transmitted such as usernames and passwords. An attacker may also actively inject/remove content from the communication, allowing the attacker to forge and omit information, inject malicious scripting, or cause the client to access remote un-trusted content. An attacker may also redirect the communication in such a way that the website and client are no longer communicating with each other, but instead are unknowingly communicating with the attacker in the context of the other trusted party.

They use packet sniffers to read the communications over a network. Anything unencrypted can be read easily.
But we forget about encrypting
Cookies Web services Intranet communications Database requests AJAX communication Pages .

Anything encrypted weakly can be cracked.

Example Scenarios Scenario #1: The application has a page called redirect.jsp which takes a single parameter named url. The attacker crafts a malicious URL that redirects users to a malicious site that performs phishing and installs malware. http://www.example.com/redirect.jsp?url=evil.com Scenario #2:The application uses forward to route requests between different parts of the site. To facilitate this, some pages use a parameter to indicate where the user should be sent if a transaction is successful. In this case, the attacker crafts a URL that will pass the applications access control check and then forward the attacker to an administrative function that she would not normally be able to access. http://www.example.com/boring.jsp?fwd=admin.jsp

Require TLS for all sensitive pages.

Especially login pages!

Set the secure flag on all sensitive cookies. Configure TLS provider to only support strong algorithms. Ensure your certificate is valid, not expired, not revoked, and matches all domains used by the site. Don't neglect the backend communications.

Non-SSL requests to these pages should be redirected to the SSL page. Every Login page should use TLS.
Because the username and password would be sent in clear text if they didn't.

Set the secure flag on all sensitive cookies This requires them to be sent via SSL. Do the same for ASP.NET forms authentication cookies in web.config.

HttpCookie c = new HttpCookie("PetsName","Mouser"); c.Secure = true;

<authentication mode="Forms"> <forms loginUrl="Login.aspx" requireSSL="true" .../> </authentication>

FIPS 140-2 compliant algorithms

Use AES or Blowfish for symmetric cryptography Use SHA-256 or SHA-512 for hashing Use RSA for asymmetric (but all are okay).

Certificate errors desensitizes users to future alerts. Keep your certificates up-to-date and valid. Use wildcards for domains
Ex: if we have a cert for www.tic.com and we open reports.tic.com, the user sees a certificate error. Get a cert for *.tic.com instead of www.tic.com.

Sniffers can see more than just web pages. When sensitive, you should use TLS for:
JavaScript files with business logic AJAX calls XML web services Database communications

Many tools available to identify vulnerabilities

One such tools are
Nmap Nessus GFI Languard etc.