DADA Week 7 Writeup

This week’s speaker was Cedric, and our subject was Web Security, which is a subset of Network Security from last week but more focused on web based technologies such as browsing, URL’s and webpages.

An interesting fact we learned was that 95% of malware is delivered via the web. This doesn’t really surprised me because where else would you get malware from aside from someone sticking a USB onto your computer or some other inconvenient form of physical input? No one would bother making malware if they had to leave their basements and walk around trying to physically inject code.

Users are the weakest link in the security of a system. Not even functioning operating systems or browsers can protect an someone who can’t protect themselves. Most users of the internet are described as “impatient, lazy, self-proclaimed omniscient” or just refuse to stop clicking on whatever pops up in their faces. Makes sense since using a computer is less than a hobby for most people who have never personally dealt with malware.

Forms of Attack

Phishing, where fake links to popular webpages are sent to unsuspecting people, where they enter their valuable information such as username and password, banking info, etc.

SEO(search) poisoning, is when hackers identify popular trends on search engines using Google Trends or something and getting their malicious links onto those searches to increase the likelihood of getting clicks. Apparently in 2014 Jimmy Kimmel was the top malicious related search. Which is weird to me because he lacks any semblance of personality and is a boring host, but he panders to the biggest crowd so his popularity is high.

Fake updates and fake antivirus,  which mimics the actions of real/proper antivirus software but doesn’t actually do anything. They will pop up in your face relentlessly once installed, telling you that your system has been infected with digital ebola and for the small price of $99 you can clean it off your system for good. Pretty ironic.

URL obfuscation is making malicious links/URLs look legitimate. Here’s the link for Microsoft:

Malvertising is when hackers post ads with malware relations onto legitimate sites so people will be redirected onto bad sites from a good one.

Waterhole attacks are when hackers find commonly visited sites by prime targets(people with no antivirus or lack of computer knowledge) and injecting exploits onto those sites so they can get easy access to their target’s systems. The hacker can then identify any more “waterhole” sites to inject, and start again from there.

So many attacks, but is there any hope for defending? There are methods such as URL/domain reputation systems, which provide real-time protection in browser or network device, and site certification services to identify legitimate webpages. The best and final defense will always be user education.

Lab 1:

The first lab had us look at an application named WebGoat, which is a “poorly-secured web application, using three common attack types”. It was built from the ground up by the OWASP foundation(Open Web Application Security Project). The “goat” is basically an easy target for malicious attacks, and we host one of those on our virtual machines so we can try some of our own attacks against a dummy website.


Our prey.

The tools/weapons of choice are Tamper Data, BurpSuite and WebScarab. Tamper Data was installed as an add-on onto Firefox. I couldn’t find the other two, but I could do what I needed to do with just Tamper. Tamper Data is a tool that allows us to modify and view HTTP/HTTPS headers and post parameters.


The files provided, Linux edition.


To start the goat up, we used the command:

sudo sh ./

And then:
sudo sh ./ start8080

This would allow us to access the WebGoat webpages. The pages were located on the URL:

No internet was required, we did this with a locally hosted page.


The initial goat page.

The first attack we performed was the Stored XSS, or cross-site scripting. This means injecting client-side scripts into other people’s browsers, a form of code injection. The scenario was to log into this set up goat login page as the employee Tom, and change something which would cause Jerry(human resources(hr?)) to see a popup.


The login page.

To do this we had to put some simple javascript into one of the fields. I changed Tom’s old street to:


The hax.

This just makes a popup in the browser Jerry is using, saying “hi”. So now you log into Jerry’s account and view Tom’s profile. You will see this:


Get hacked son.

Mission accomplished.

The next form of attack: Improper Error Handling(Fail Open). This is exploiting a lack of error handling cases to access things you shouldn’t. In this instance, we had to delete one of the login parameters, either login or password, which would allow us to login.

Enabling parameters allows us to see what sort of data is being passed. Logging in would show two more parameters, “username= ” and “password= ”


The second page with “Show Params” enabled.

A hint said to force a parameter to point to a null pointer. The proper way to do this was to use WebScarab and delete username or password. Since I couldn’t find either of those, I just created a null myself.


Password is null.

Which allowed me to force a login.


The second attack complete.

The last attack is Numeric SQL Injection. SQL is the querying language used to manage data. This means sticking some SQL code where it doesn’t belong. Using Tamper Data, I could modify the post parameters being sent.

We were supposed to inject SQL so we could display all the weather data from every station in one table rather than just a single station at a time.

SELECT * FROM weather_data WHERE station = 101


SELECT * FROM weather_data WHERE station = 101 or 1=1

Which returned the entire table at once, rather than one station at a time.



We were also asked to do the same thing but through modifying the GET parameters instead. The result is displayed below.



We had to create a web form vulnerable to reflected cross site scripting then fix it. The other option was to do the same thing but for our professor’s old site. It was vulnerable, but there was no python code in sight, so I went with option 1.


The html page vulnerable to reflected XSS.


My webpage. Uses GET to echo out a name and email.


The fixed page. No longer creates an alert box.


Option 2. Hack the processor’s old site. It was vulnerable for reflected XSS attacks but there was no form to modify.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s