Open Redirector Vulnerabilities

          Open redirector is a type of web application vulnerability. It is very easy to understand and exploit.

Working:

Open redirect occurs when a page takes a URL as a parameter (through form or anything) and redirects the user to that URL without validation. Here is a sample PHP code which is vulnerable to Open Redirect.

<?php
$vuln = $_GET["url"];
header('Location: ' . $vuln);
?>

          It accepts a GET request parameter called 'url' and redirects the user to the address specified in this parameter. For example, save the above code as "redirect.php" on your local www root directory and access the page from your browser as follows:

http://127.0.0.1/redirect.php?url=http://www.google.com

This page will simply redirect you to the address specified (in this case, google.com) without checking its malicious or not. You can replace www.google.com with any other URL and it will work just fine.

Applications:

Open redirect vulnerabilities are mainly used for phishing. The victim is given a specially crafted link to the open redirector page. This open redirector page gets the malicious link through parameter where it redirects the user to. For example,

http://www.example.com/redirect.php?url=http://www.malicious.com

In this case, example.com is a trusted domain. Innocent users get tricked into believing that the link leads them to example.com (and therefore, it is trusted) whereas in reality, they will get redirected to malicious.com which can have phishing traps waiting for them. 

URL Obfuscation:

From the above link, it is very easy to determine that there is something phishy with the link. The malicious site which this website will redirect to is clearly visible and readable. Hence, there are some techniques of URL obfuscation that can be used to hide this malicious address. Here are few ways of doing so...

• Directory Traversal
• Hex Encoding

In directory traversal, you add random directory names in the PATH part of URL such that malicious address is further pushed to the right and victim is likely to ignore that as a part of long and complex link. For example, 

http://www.example.com/security/auth/ODialogue/../../../redirect.php?url=http://www.malicious.com

Hex encoding is a way of encoding characters of a URL into hexadecimal, separated by a % sign. It can completely encode the malicious address present in the URL such that user has no way of knowing which malicious address is there just by looking at the link. For example,

127.0.0.1/redirect.php?url=%68%74%74%70%3A%2F%2F%77%77%77%2E%67%6F%6F%67%6C%65%2E%63%6F%6D

In this link, I have hex encoded the address "http://www.google.com". It can be, of course, replaced by any other address.

Prevention:

To avoid open redirects, it is necessary to code the redirecting pages in such a way that they will validate the address before redirecting to it. Many websites do this by implementing "trusted redirects" (I dont know the actual name for it. If you do, please mention in comments!). They have a database of trusted web addresses i.e. the addresses which they will trust in redirecting their users to. So whenever the redirect page is called, it checks if the address it got from parameters exists in its trusted database. If it is present, the redirector will happily forward the user to that address. If it is not, they will probably show a warning or take the user back to previous page. This is indeed a good practice but there is a little workaround for it ;)

Bypassing Trusted Redirects:

For as much as I have seen, most of the trusted redirects will only check the domain part of the address that they are forwarding to. If the domain part matches with something in the table of trusted websites, you are good to redirect to. But what if one of your trusted websites has an XSS vulnerability? ;)

With an XSS vulnerability, you are able to replace the current page with any other address you wish. For example, consider the URL:

127.0.0.1/xss.php?search=<script>window.location='http://www.google.com';</script>

It will inject the javascript code into the page which will redirect you to the address specified. (in this case, google.com)

Now consider, what if we pass this exact URL to the open redirect vulnerable page that we discovered earlier? Here is the specially crafted URL.

http://www.example.com/redirect.php?url=http://www.trusted.com/xss.php?search=<script>window.location='http://www.malicious.com';</script>

Here, example.com is our own (assume, reputed) site whose users are going to be phished.
trusted.com is a website whom we trust redirect our users to.
malicious.com is the attacker's phishing page.

When a victim executes above URL, the following actions take place in sequence:

1.   The browser connects to example.com and asks for redirect.php page. It also passes everything after the first "?" sign as parameter.
2.   The redirect.php finds the 'url' parameter along with the value which is "http://www.trusted.com/...".
3.   It finds trusted.com in its own list of trusted sites and happily redirects user to this URL, not bothering to see what the rest of the URL is.
4.   The browser connects to trusted.com and requests xss.php page (which is vulnerable to XSS :P ). It also passes everything after the second "?" sign as parameter.
5.   The xss.php receives the "search" parameter along with the value which is Javascript code to be injected.
6.   Since xss.php is vulnerable, somewhere in its output page (which will be sent to the browser) it will have the value of "search" parameter, which is the injected code.
7.   The browser receives the page with injected code, it starts parsing and loading the page. It comes across the injected Javascript code.
8.   Since there is no way for browser to know that it is injected javascript, it starts executing it.
9.   The execution of window.location... statement will stop loading the current page and instead it will load URL mentioned in the window.location property instead. (This URL is the attacker's malicious page)
10.   The browser finally contacts malicious.com and the malicious page (which is most likely a phishing page) is displayed to the user.
(phew!)

So, as you can see, this is a very sophisticated way of bypassing trusted redirects. The user gets routed from 2 different sites before landing on our malicious page! :D Please note that this works on Firefox. Doesnt work on chrome. Never bothered testing on IE ;) . 

THIS INFORMATION IS STRICTLY FOR EDUCATIONAL PURPOSES AND I AM NOT RESPONSIBLE FOR ANY TROUBLE YOU FIND YOURSELF IN WITH IT.

Thank you for reading, good night :)

Implementation of Apriori Algorithm

          Apriori algorithm is used for finding frequently occurring items and associative rule mining from from an input database which is transactional. Associative rule mining and Apriori algorithm are part of a bigger domain of data mining. Data mining is basically the process of discovering patterns in large data sets. There can be many applications of apriori algorithm e.g. market basket analysis. Here is a link I found particularly useful for learning Apriori Algorithm and associative rule mining:

http://www.cs.uic.edu/~liub/teach/cs583-spring-12/cs583.html

I have implemented the first two passes of Apriori Algorithm as a part of an academic assignment. It was for constructing attack graphs which are used for threat prediction and vulnerability assessment. The algorithm is implemented in python and its very simple. It can be extended for k passes of the algorithm.

Here is the code:

minsup = 0.3
minconf = 0.8 

def count_first(transactions):
    adict = {}
    for t in transactions:
        for item in t:
            if item in adict:
                adict[item] += 1
            else:
                adict[item] = 1
    return adict 

def find_frequent(Candidate, minsup, no_of_lines):
    adict={}
    for key in Candidate:
        if ((float)(Candidate[key]/no_of_lines)) >= minsup:
            adict[key] = Candidate[key]  
    return adict 

def candidate_gen(keys):
    adict={}
    for i in keys:
        for j in keys:
            if i != j and (j,i) not in adict:
                adict[tuple([min(i,j),max(i,j)])] = 0
    return adict 

def add_frequency(Candidate, transactions):
    for key in Candidate:
        for t in transactions:
            if key[0] in t and key[1] in t:
                Candidate[key] += 1
    return Candidate 

f = open("testcase.txt","r")
transactions = []
no_of_lines=0 

for line in f:
    split_line = line.split()
    transactions.append(split_line)
    no_of_lines = no_of_lines + 1 

print(no_of_lines) 

#First iteration
C1 = count_first(transactions)
F1 = find_frequent(C1,minsup,no_of_lines)
#Second iteration
C2 = candidate_gen(F1.keys())
C2 = add_frequency(C2,transactions)
F2 = find_frequent(C2,minsup,no_of_lines)
print(F2)

It accepts input data from the file "testcase.txt". In this file, each new line represents one transaction. Each such transaction contains items represented by 'integers' and separated by spaces. So, essentially, each line is a collection of integers separated by spaces.

The program makes two passes of apriori over input data. It outputs pairs of frequent item sets along with their 'support' metric values. 

Comments and suggestions are welcome :)