Server-side: 'POST' Method

Unlike the get method, values passed over post method are not shown in the URL, which is why this method is chosen for most login/signup fields on the web. Another advantage of this method is that users cannot do malicious things by manipulating the URL. However, one disadvantage that it has is that this high security can sometimes make it hard to debug a web application. When working on a web application it is always a good practice to passed the values through 'GET' method first and then use 'POST' method once you are sure everything is ok.

Well Known Hacks II: XSS (Server-side: 'GET' Method)

In this post I briefly talk about how some people take advantage of security flaws in server-side scripts. One very common way is by passing some variables to a script. Before getting to talk about this, I need to talk about 'GET' and 'POST' methods in form submissions. In this post talk about 'GET' method, and in next post I will post things about 'POST' method :).

Once you submit a form on a webpage (such as Login form, sign up form, etc.)  the data you entered in each of the text fields are passed to a script (could be the same script, or another script on the same domain), and that script handles your data. The data passed to the script are usually transferred using either of the 'GET' or 'POST' methods. The main difference (in terms of their behaviour) of these two is that if the field data are passed using 'GET' method, all the variable values can be seen in the URL. To make this clear let me show you an example. Let's inspect the following link that searches a query in Bing.com:

http://www.bing.com/search?q=behnam+azizi+cgi

As you saw, after you clicked on the link, it searched the query "behnam azizi cgi" using Bing search engine. This is obviously done using 'GET' method as you can see the value of the variables passed to the script (In this case variable q has value "behnam azizi cgi". In other words q="behnam azizi cgi"). Now what the script on the server does is that it reads the value of the variable 'q' and uses the search engine to search for this query.

Of course, in my opinion, this is an advantage of Bing (As far as I know Google does not allow you to do this probably because of security issues), that you can search something using 'GET' method. One advantage that it has is that if you are working on an application and inside the application you want to allow the user to search the web, you can easily use Bing search engine (I bet Microsoft did this on purpose so at least some developers use Bing).

It is true that no one would use Bing transfer user's private data (such as username, password, etc.) using 'GET' method (sorry for the scratch. I forgot to write in pencil :) ). But it is always useful to know about the existence of such a thing (I know from now on you will be using Bing as your favorite search engine :D ).

In the next post I will talk about post method, and (possible) ways that it could be exploited.

Well Known Hacks II: XSS (Client-side Examples)

As promised previously, in this post I am going to give some XSS attack examples. I will present here 2 simple examples with actual JavaScript code that you can try in your browser. Examples that I present here are done using Google Chrome or Chromium (The open-source version of Google chrome on Linux). If you have any other browsers like FireFox or Opera you could still try these examples as I am quite sure they have their own JavaScript debuggers (For example: An extension named FireBug that enables you to debug JavaScript in FireFox browser).

First Example: Changing the background of Facebook!

Change your Facebook background with these 4 easy steps:

1) If using Chrome, right click on an empty spot on the page and then click on 'Inspect Element' (alterntively, you can press Ctrl+shift+j). In other browsers procedure is quite similar.

2) From the available tabs that you can see select the 'console' tab
3) Paste the following JavaScript code into the console:

var imgdiv = document.getElementsByTagName("body");
var bg = prompt("Enter image URL:", "http://static.freepik.com/free-photo/abstract-seamless-floral-pattern-background_50-15060.jpg");
imgdiv[0].style.backgroundImage = "url(" + bg + ")";
imgdiv[0].style.backgroundAttachment = "fixed";


4) At this point you can either enter the URL to your own image on web OR just press enter

Second Example: Changing Google logo!
This example is quite similar. Open JavaScript console and paste the following code into it. Once it asks for image URL you can enter the URL to your own image (OR just press enter if you really like to see my name you Google home page! :D).

var bg = prompt("Enter image URL: ", "https://lh5.googleusercontent.com/-55mfElJWy1w/Ux6GrxX8u-I/AAAAAAAAAow/KXQy3DtaEBI/w323-h110-no/Behnam.gif");

document.getElementById("hplogo").style.backgroundImage = "url(" + bg + ")";

Well Known Hacks II: XSS (JavaScript Injection)

In this topic I am going to talk about a new (and pretty exciting in fact), type security breach, namely XSS attacks. For your information, XSS stands for Cross Site Scripting (so the 'X' in XSS is not actually an 'x' but a cross!).

First of all, I divided the whole thing into two sub-types: JavaScript injection (client-side vulnerability), and server-side vulnerability. In this post specifically I talk about client-side vulnerability. In the next post, I give some AMAZING examples, and in later posts I will talk about server-side vulnerability as well.

The main idea before JavaScript injection is that you write a JavaScript code and then you can use various tricks to execute you code along the code sent to your browser by a website. At first glance this may seem quite normal and safe, however, IT IS NOT! Accoring to Symantec Security Threat Report, XSS attacks included more than 84% of all security threats in year 2007. You can view the article here.

By executing your own code along with the script sent to your browser by the server, you can manipulate the webpage the way that YOU want. It may be partially safe in a sense that this only changes the client-side view of the webpage and have no effect on the server (and this is in fact true). But there are other vulnerabilities that are important concerns:

1) Self-XSS Attacks: This basically means that by injecting code into a webpage you can access user's private data, where user is anyone who uses the browser. For example: A few months ago, I wrote a JavaScript code that stores usernames, and password of users who use my own computer to login into popular websites such as: Facebook, Gmail, etc (If you are a friend of mine, you don`t want to use my computer to browse the web). This is probably one of the most prevalent (and quite annoying) type of XSS attack. Facebook itself was a target of Self-XSS attacks long time ago. Remember it or not, there was type when you received links from your friends like: "99% of people can't watch this video for more than 10 seconds". And once you clicked on the link, the same link got sent to all your friends (Quite annoying and embarrassing huh?). Facebook itself has a page that talks about such attacks:  

Matt Jones - Self-XSS attack explained | Facebook 

But There are also useful types of JavaScript injections, example? AdBlock is one of them!.But again, even in this case you should be very careful! Such applications can access not only all your browsing data, but also they can keep track of your many other activites (including login into webpages using user/password)! To see what information each of these applications can access in your browser you should ALWAYS look at their permissions. For example, if using Chrome, you can look at permissions of your applications by going to Tools->Extensions

2) Brute-Force Guessing: Using this technique you can inject different values into online forms and submit them automatically over many iterations. For example, I have may have an online homework that requires putting numbers or words and clicking on 'submit' (or something similar) button. If there are no limited number of trials, and considering that the whole page does not refresh after each submit, you can write a JavaScript code that injects many different values into the form and automatically clicks on 'submit' button until you get the correct answer!

Changing the design of a webpage (in these cases FB, and Google) using JavaScript injection. In these examples some images are changed by entering my username, and a specific password into the login form (In the FB image above) or by adding 'u=behnam' in the URL field (The modified Google above).

Image Source: My computer screenshot

Well Known Hacks I: SQL Injection (Examples)

Now in this post I will briefly mention some of the common SQL Injection attacks. Please note that none of the examples presented here are mine, and they are taken from Steve Friedl's Unixwiz.net Tech Tips (You can visit the webpage for more detailed instruction).

Suppose there is a login form where you enter some data. The main methods of SQL injection involve entering values into the forms such that they make statements which are acceptable by the SQL parser.

Exploiting Using a Trivially True Logical Statement:

SELECT fieldlist
  FROM table
 WHERE field = 'anything' OR 'x'='x';

As you can see in the above example: We have a logical statement which is always true. No matter what you put there instead of 'anything', the comparison 'x'='x' is always true (Note the exploitation of quotations. We put there <'x'='x> as input, but from the machine's point of view, the value to be parsed is <'x'='x'>)! Therefore, if the victim program or application were not secure enough, you will be granted access to the system!

Brute-Force Password Guessing:

SELECT email, passwd, login_id, full_name
  FROM members
 WHERE email = 'bob@example.com' AND passwd = 'hello123';

Suppose another case where there is a form which asks for a valid email. Given that you know bob's email (bob@example.com), you can enter the above value as shown in the box over many iterations to find Bob's password using an efficient brute-force algorithm. What you do is that you run the above statement over many iterations but each time give a different value as the password (preferably trying combinations of different words in a dictionary as passwords). Once the system confirms that your email valid, that actually means that you have managed to hack Bob's password! Because otherwise the above statement would be false and from the point of view of machine's logic, as long as the password is wrong the whole statement becomes wrong (look at the AND operator), and finally the email is not considered as a valid email.

There are countless of more SQL injection examples that I am not going to talk about here, but you can definitely find articles on the web. Besides, SQL injection can be prevented very easily (I know it's sad, but you will never become a grey-hat hacker by solely knowing about SQL injections).

In my next blog post I will talk about a more practical type of hacking (namely XSS Attack).
P.S. It never hurts to follow my blog by clicking the follow button on top-right side of the page.

Well Known Hacks I: SQL Injection (Introduction)

In this topic and a few next topics, I am going to talk about some of the well-known hacks that hackers use to breach into information systems. In this blog post specifically, I am going to talk about what SQL  is, and I briefly talk about SQL Injection. In next blog post I give examples of famous SQL injections.

To begin with, SQL is a programming language, firstly developed by IBM, that enables computers to store, and retrieve data fairly efficiently (at least in terms of the amount of coding that programmer have to do SQL is very efficient). SQL is used by many companies worldwide. SQL is categorized into a type of  DBMS (Data Base Management Systems) known as Relational Databases. Relational database query languages (e.g., SQL, MySQL, YQL etc) are very easy to learn, and fairly efficient.

One disadvantages that Relational databases have, however, is that once the amount of data is so huge, they do not scale well. For the same reason, some big companies such as Google, Facebook, etc. do not use SQL or any other DBMS because of this lack of scalability.

Now I think I have gave you enough information about SQL. Let`s get to the main topic (i.e., SQL injection). SQL syntax, although very efficient, is in a way that can be abused by using special characters such as dashes, quotations and sometimes even logical operators (such as AND, OR, etc.). Of course, you should note that an application can be made secure enough to be immune against such attacks, but for that matter, the programmer has to actually know about the existence of such security threats and how to prevent them. I will mention SQL injections by example in my next post. But just to make your mind ready, I start with an example:

SQL injection starts with inputs that you give to a form in a website or application. For example, the (web) application has a form with separate fields that ask you for your name, password and/or email. SQL injection is basically values that you can enter in these fields to trick the application into granting you access to data that you should not normally be able to access.

In my next posts I will mention a few SQL injection commands and their usage.

Image Source: 

<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZw5EevVeVkf5EL0V5w5kdexNwPB3NWwCGCuRUagW-C7m5YPtAPNAGIwIU3yBmYirQldalj4TlMzC5yn1SC3TprTUeDnQaXXSWghgaJLaiVM_oxgA-LdSikMp_Psz4ZwG45iyjC_BD9Rqf/s1600/sql_injection.gif>

Unit Testing, and programming test cases

Here I am going to talk about a fairly different aspect of programming, namely unit testing. The idea is that once you write a program or a piece of code, you can write another program that gives arbitrary inputs to your program to test it against bugs and issues. In other words, it is like you make a bot that tests your program against bugs (Instead of you tesing them on your own). There are various methods to do this, and there are various packages (e.g., JUnit for Java) that enable you to test your program. Here I am going to talk about a very simple one.

If your operating system is Unix, you can use Unix pipes for unit testing (If you do not already know, in short words a pipe is a method to give the output of a file or script to the input of another script). Similarly if you have windows you can do the same with windows pipes. Here is a very simple example from one of my old facebook posts:

with Unix pipes you can write test cases for your program. For example:
"$ echo 34 | ./main"
gives the integer "34" to executable file "main" as an input ('|' is the pipe operator).

For example I have an executable pw.cpp which gives the output "unlocked" if a certain password is given as input once the program is run (password is 'hello' in this case). As follows:

//================ START ===========
#include <iostream>
#include <string>
using namespace std;

int main(){
string x;
cout << "Enter password: ";
cin >> x;

if (x == "hello")
{
cout << "unlocked\n";
}else{
cout << "Wrong\n";
}

return 0;
}
//============== END ============

But in case I have no access to the actual source code, it seemed impossible for a normal human to run the above program many times and try all passwords ...

However, the following Python script reads a set of English words from a dictionary file containing most common English words ('dict_MC.txt' in below) and gives them as input to the above program, until the desired password is found (and as you can see it makes use of Unix pipes to give inputs to the above program):

#========== START ==========
import os, sys, subprocess

words = [lines.strip() for lines in open("dict_MC.txt")]

for x in words:
f = os.popen('echo "' + str(x) + '" | ./pw')
#print "input given: " + x
if (f.read() != "Enter password: Wrong\n"):
print "password is " + str(x)
break
#=========== END ================

Of course if the password were more complicated it would take up to hours to find it.

More about security: Same-Origin Policy

In this topic I am going to talk about same-origin policy. In one of the previous posts I talked about AJAX (i.e., a method to communicate with the server without the need to refresh the whole web page page); Now one question that may arise is that:

'What if someone sends many AJAX requests to a login script in a website (e.g., Facebook, Yahoo! etc.) and try all different combinations of usernames and passwords to hack into users accounts?'

Fortunately, for security reasons modern-day client-side languages such as JavaScript do not allow AJAX requests to be sent from a script to another script on a different domain. For example, in order to send AJAX requests to "https://www.facebook.com/login.php" (Script that handles user log-ins to Facebook.com) you need to have your own script put on the 'Facebook.com' domain. In other words, you can only send AJAX requests to scripts that are located on the same domain where your own file (script) is located. This rule is known as same-origin policy.

However, it does not end all here. What if you are one of the creators of programming languages such as JavaScript? or what if you can somehow manipulate these languages or create a new browser-side language that can violate this policy?

If you did not already know, you should know that your information in the world wide web it is by no means secure ...