Input Validation Attacks :-
Input Validation Attacks are where an attacker intentionally sends unusual input in the hopes of confusing the application.
The most common input validation attacks are as follows-
1) Buffer Overflow :- Buffer overflow attacks are
enabled due to sloppy programming or mismanagement of memory by the
application developers. Buffer overflow may be classified into stack
overflows, format string overflows, heap overflows and integer
overflows. It may possible that an overflow may exist in language’s
(php, java, etc.) built-in functions.
To execute a buffer overflow attack, you merely dump as much data as
possible into an input field. The attack is said to be successful when
it returns an application error. Perl is well suited for conducting this
type of attack.
Here’s the buffer test, calling on Perl from the command line:
$ echo –e “GET /login.php?user=\
> `perl –e ‘print “a” x 500’`\nHTTP/1.0\n\n” | \
nc –vv website 80
This sends a string of 500 “a” characters for the user value to the login.php file.
Buffer overflow can be tested by sending repeated requests to the application and recording the server’s response.
2) Canonicalization :- These attacks target pages
that use template files or otherwise reference alternate files on the
web server. The basic form of this attack is to move outside of the web
document root in order to access system files, i.e.,
“../../../../../../../../../boot.ini”. This type of functionality is
evident from the URL and is not limited to any one programming language
or web server. If the application does not limit the types of files that
it is supposed to view, then files outside of the web document root are
targeted, something like following-
/menu.asp?dimlDisplayer=menu.asp
/webacc?User.asp=login.htt
/SWEditServlet?station_path=Z&publication_id=2043&template=login.tem
/Getfile.asp?/scripts/Client/login.js
/includes/printable.asp?Link=customers/overview.htm
3) Cross-site Scripting (XSS) :- Cross-site
scripting attacks place malicious code, usually JavaScript, in locations
where other users see it. Target fields in forms can be addresses,
bulletin board comments, etc.
We have found that error pages are often subject to XSS attacks. For
example, the URL for a normal application error looks like this:
http://website/inc/errors.asp?Error=Invalid%20password
This displays a custom access denied page that says, “Invalid password”. Seeing a string
on the URL reflected in the page contents is a great indicator of an XSS vulnerability. The attack would be created as:
http://website/inc/errors.asp?Error=<script%20src=…
That is, place the script tags on the URL.
4) SQL Injection :- This kind of attack occurs when
an attacker uses specially crafted SQL queries as an input, which can
open up a database. Online forms such as login prompts, search
enquiries, guest books, feedback forms, etc. are specially targeted.
The easiest test for the presence of a SQL injection attack is to append
“or+1=1” to the URL and inspect the data returned by the server.
example:- http://www.domain.com/index.asp?querystring=sports’ or 1=1–