ethicalhack3r

I wanted to start reading the RFC 2616 HTTP/1.1, because who knows more about how HTTP works than the inventors right?! The only problem was, is that I hate reading large documents from screens, I lose concentration after very little time and end up on Twitter or some other social networking site.

So I started looking for printed RFCs, someone must have put these in a book?! Well, it turns out that I couldn’t find any. I thought about printing the entire RFC from my university library (£0.10 a page) however RFC 2616 contains 176 pages (£17.60 total). I remembered that OWASP use lulu.com for printing their awesome books, so I decided to print my own RFC and make it into a book. After many hours of trying to fit the A4 RFC into a pocket-size (4.25″ x 6.88″) book, getting the font size right, aligning the page numbers and getting the formatting just right on all 176 pages, ‘rfc in your pocket’ was ready to upload! After lots of trial and error with reformatting and trying to get the whole thing to fit I decided to order one for myself.

I was really surprised with the quality of the finished product! It even fits in my pocket!

So now I figure why not sell it and let other people have their very own RFC in their pocket with out having to go through all the hassle I went through. It turns out that RFCs can be distributed etc, as long as you keep in the original copy-write notice intact. But I’m making money of other peoples work! That’s not very ethical.

Here’s how much the whole thing costs:

Manufacturing: £4.29

My Revenue: £0.57

Lulu’s Revenue: £0.14

Book selling price: £5

What I have decided to do is give 50% of my revenue per book sale to ihackcharities, that means that I earn £0.285 per book sale and so does ihackcharities. That way I get something for my hard work and the rest goes to a good cause.

You can buy the ‘RFC 2616 -HTTP/1.1′ rfc in your pocket book from here:

http://www.lulu.com/product/paperback/rfc-2616—http11/6007891

I plan to do more if this one sells enough and there is demand for other rfc’s in your pocket.

When Microsoft launched their new Internet Explorer (IE) 8 browser in March of this year, it boasted a new security feature which filtered malicious scripting code to prevent reflected type 1 XSS attacks known as the ‘XSS Filter’.

Cesar Cerrudo, while IE8 was still in BETA found a way to bypass the filter by using a ‘2 stage XSS attack’:

A 2 stage XSS attack is when the user has to browse to a second URL after browing the initial URL for the XSS attack to take place, people may think that this attack is compliated and not reliable but it’s simple and very realiable and has almost the same success rate as 1 stage XSS attack since people want to get what they were looking when browsing to the first URL they will continue browsing most of the time.

Here is a screenshot from a test against DVWA using the 2 stage attack payload which he provides on his blog:

As you can see I was using the latest IE8 at the time on a fully patched Windows Vista box with the filter enabled:

Here is another bypass using a different payload:

Microsoft have taken a great step forward in actively protecting their customers against XSS attacks and I believe that in part they have, however the XSS Filter still has a lot of room for improvement. There are other known bypasses against the filter which can be found in the reference list below along with other sources of information.

References:
http://en.wikipedia.org/wiki/Internet_Explorer_8
http://blogs.msdn.com/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx
http://nomoreroot.blogspot.com/2008/08/ie8-xss-filter.html
http://kuza55.blogspot.com/2008/09/ie8-xss-filter.html
http://www.80sec.com/ie8-security-alert.html

Today is exactly one year on after posting my first post on the blog. I had a premature celebration (couldn’t hold the excitement) by changing the design as you have all probably noticed. I am still working on he re-design so there may still be some glitches here and there, bear with me.

I have come a long way since that first post and learnt a great deal. In 12 months I have created and managed DVWA to the success it is now with lots of help from the community. I have done talks, written articles and been a guest on some great podcasts. I completed my first year at university with the grade I set out to achieve and I am now half way through my second year still going strong.

All this I could not have achieved with out my friends, family and the online security community. The infosec community is always there to lend a hand and has opened up great opportunity’s for me. If you are an Ethical Hacking student or security professional and your not involved in the community, I cant stress enough how beneficial it is to contribute and learn from the amazing people that our out there. I would like to name names however there’s so many of you that have helped me I’m afraid I might miss some one out.

With out you the reader there would be no point in me keeping the blog updated with new posts, so please comment, give feedback and let me know what you would like to see more of. Also, don’t forget to subscribe! Blue box on the right. ;) –>

Again a big thank you to you all.

The World Wide Web and the applications that run on it have come a long way since the invention of HTML by Tim Berners-Lee (British man I might add) in the early 1990’s. Back then the World Wide Web was a static web of text, images and hyperlinks. Nowadays we have the privilege (sometimes not) of having whole communities which solely exist in a dynamically evolving cyberspace with wikis, blogs, social networking, video sharing and a lot more. “Web 2.0” would not exist without the complex web applications that run on the millions of web servers across the globe.

So how do we go about securing our web applications?

There are many different ways in which web applications can be made more secure. In this article I am going to cover a few tools and techniques which make this possible.

WAF:
Web Application Firewall’s are applications which filter HTTP traffic looking for malicious code which could be used in attacks such as SQL Injection , Cross Site Scripting (XSS), File Inclusion and more.

According to OWASP (Open Web Application Security Project), the important criteria in selecting a WAF is the following:

Very Few False Positives
Strength of Default
Power and Ease of Learn Mode
Types of Vulnerabilities it can prevent
Ability to keep individual users constrained to their current session
Ability to be configured to prevent ANY specific problem
Form Factor: Software vs. Hardware

Web Application Vulnerability Scanners:
Web Application vulnerability scanners help improve security and minimise the risk of the application being exploited by automatically crawling the site actively looking for vulnerabilities. Once the scan has been completed the web application scanner will produce a report with its findings which a professional information security practitioner should then investigate and patch. These scans should be run on a regular basis.

Updates/Patches:
When using ready-made web applications such as blogs, CMSs, wikis, etc. It pays to keep the application updated to the latest version and patched against the latest bugs. Ready-made web applications are often targeted for their wide deployment. If a SQL Injection vulnerability is found within a bespoke application, it would only affect that particular application. However if a SQL Injection vulnerability was found in WordPress for example it would affect their nearly 8 million version 2.8 users (at the time of writing) including big names such as PlayStation, EBay and others. This is what makes ready-made web applications a bigger target and why it pays to keep software updated and patched.

References:
http://www.rfc-editor.org/rfc/rfc1866.txt
http://www.owasp.org/index.php/Web_Application_Firewall
http://wordpress.org/download/counter/
http://wordpress.org/showcase/