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=
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–
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=
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–
