DATA VALIDATION TESTING
Testing for Cross site scripting
In Cross Site Scripting (XSS) testing, we test if it is possible to manipulate the input parameters of the application so that it generates malicious output. We find an XSS vulnerability when the application does not validate our input and creates an output that is under our control. This vulnerability leads to various attacks, for example, stealing confidential information (such as session cookies) or taking control of the victim's browser. An XSS attack breaks the following pattern: Input -> Output == cross-site scripting
In this guide, the following types of XSS testing are discussed in details:
1. Testing for Reflected Cross Site Scripting
A black-box test will include at least three phases:
1. Detect input vectors. The tester must determine the web application’s variables and how to input them in the web
application. See the example below.
2. Analyze each input vector to detect potential vulnerabilities. To detect an XSS vulnerability, the tester will typically use
specially crafted input data with each input vector. Such input data is typically harmless, but trigger responses from the web
browser that manifests the vulnerability. Testing data can be generated by using a web application fuzzer or manually.
3. For each vulnerability reported in the previous phase, the tester will analyze the report and attempt to exploit it with an
attack that has a realistic impact on the web application’s security.
Result :
i’m try to use mimmoo as user
http://www.akakom.ac.id/index.php?user=mimmoo
this is not works, but the web does not give any response. (eg message failed / message successful)
then i’m try to to insert a script in the url :
http://www.akakom.ac.id/index.php?user=<script>alert(123)</script>//
but after that url instead turned into:
http://www.akakom.ac.id/index.php?user=%20script%3EALERT%20123%20%20%2Fscript%3E#06346854087064835493
2. Testing for Stored Cross Site Scripting
because I can not log on and always fail to register as a user, then I insert scripts for Stored XSS. but the results do not exist, the web does not respond to the script that I paste.
alert(document.cookie)
3. Testing for DOM based Cross Site Scripting
DOM-based Cross-Site Scripting is the de-facto name for XSS bugs which are the result of active content on a page, typically JavaScript, obtaining user input and then doing something unsafe with it to lead to an XSS bug. This document will only discuss JavaScript bugs which lead to XSS.
Blackbox testing :
Blackbox testing for DOM-Based XSS is not usually performed since access to the source code is always available, as it needs to be sent to the client to be executed.
4. Testing for Cross Site Flashin
ActionScript is the language, based on ECMAScript, used by Flash applications when dealing with interactive needs. ActionScript, like every other language, has some implementation patterns which could lead to security issues. In particular, since Flash applications are often embedded in browsers, vulnerabilities like DOM based Cross Site Scripting
could be present in flawed Flash applications.
5. SQL Injection
In SQL injection testing, we test if it is possible to inject data into the application so that it executes a user-controlled SQL query in the back-end DB. We find a SQL injection vulnerability if the application uses user input to create SQL queries without proper input validation. A successful exploitation of this class of vulnerability allows an unauthorized user to access or manipulate data in the database. Note that application data often represents the core asset of a company. A SQL Injection attack breaks the following pattern: Input -> Query SQL == SQL injection
SQL Injection testing is further broken down into:
1. Oracle Testing
2. MySQL Testing
3. SQL Server Testing
4. MS Access Testing
5. Testing PostgreSQL
In SQL injection testing, we test if it is possible to inject data into the application so that it executes a user-controlled SQL query in the back-end DB. We find a SQL injection vulnerability if the application uses user input to create SQL queries without proper input validation.
i’m try to :
username = 1′ or ’1′ = ’1
password = 1′ or ’1′ = ’1
but still failed
6. LDAP Injection
LDAP injection testing is similar to SQL Injection testing. The differences are that we use the LDAP protocol instead of SQL and that the target is an LDAP Server instead of a SQL Server. An LDAP Injection attack breaks the following pattern: Input -> Query LDAP == LDAP injection
Blackbox testing :
http://www.akakom.ac.id/ldapsearch?user=*
7. ORM Injection
ORM injection testing is similar to SQL Injection Testing, as well. In this case, we use a SQL Injection against an ORMgenerated data access object model. From the tester’s point of view, this attack is virtually identical to a SQL Injection attack. However, the injection vulnerability exists in the code generated by an ORM tool.
Black box
Black box testing for ORM Injection vulnerabilities is identical to SQL Injection testing (see Testing for SQL_Injection.) In most cases, the vulnerability in the ORM layer is a result of customized code that does not properly validate input parameters. Most ORM software provides safe functions to escape user input. However if these functions are not used, and the developer uses custom functions that accept user input, it may be possible to execute a SQL injection attack.
8. XML Injectio
In XML injection testing, we test if it possible to inject a particular XML document into the application. We find an XML injection vulnerability if the XML parser fails to make appropriate data validation.
An XML Injection attack breaks the following pattern:
Input -> XML doc == XML injection
Blacbox testing
When a user register himself by filling an HTML form, the application will receive the user’s data in a standard request, which for the sake of simplicity will be supposed to be sent as a GET request.
http://www.akakom.ac.id/addUser.php?username=mimmoo&password=18181818&email=ssbella18@gmail.com
but its not works
9. SSI Injection
Web servers usually give developers the ability to add small pieces of dynamic code inside static HTML pages, without having to deal with full-fledged server-side or client-side languages. This feature is incarnated by Server-Side Includes (SSI) Injection. In SSI injection testing, we test if it is possible to inject into the application data that will be interpreted by SSI mechanisms. A successful exploitation of this vulnerability allows an attacker to inject code into HTML pages or even perform remote code execution.
10. XPath Injection
XPath is a language that has been designed and developed primarily to address parts of an XML document. In XPath injection testing, we test if it is possible to inject data into an application so that it executes user-controlled XPath queries. When successfully exploited, this vulnerability may allow an attacker to bypass authentication mechanisms or access information without proper authorization
11. IMAP/SMTP Injection
This threat affects all the applications that communicate with mail servers (IMAP/SMTP), generally webmail applications. In IMAP/SMTP injection testing, we test if it possible to inject arbitrary IMAP/SMTP commands into the mail servers, due to input data not properly sanitized. An IMAP/SMTP Injection attack breaks the following pattern:
Input -> IMAP/SMTP command == IMAP/SMTP Injection
12. Code Injection
In code injection testing, we check if it is possible to inject into an application data that will be later executed by the web server. A Code Injection attack breaks the following pattern:
Input -> malicious Code == Code Injection
13. OS Commanding
In command injection testing, we will try to inject an OS command through an HTTP request into the application. An OS Command Injection attack breaks the following pattern:
Input -> OS Command == OS Command Injection
Black box testing :
http://www.akakom.ac.id/cgi-bin/userData.pl?doc=user1.txt
14. Buffer overflow
In these tests, we check for different types of buffer overflow vulnerabilities. Here are the testing methods for the common
types of buffer overflow vulnerabilities:
1. Heap overflow
2.Stack overflow
3. Format string
In general Buffer overflow breaks the following pattern:
Input -> Fixed buffer or format string == overflow
15. Incubated vulnerability Testing
Incubated testing is a complex testing that needs more than one data validation vulnerability to work. In every pattern shown, the data should be validated by the application before it's trusted and processed. The goal of our testing is to verify if the application actually performs validation and does not trust its input.
16. Testing for HTTP Spltting/Smuggling
Describes how to test for an HTTP Exploit, as HTTP Verb, HTTP Splitting, HTTP Smuggling.
In Cross Site Scripting (XSS) testing, we test if it is possible to manipulate the input parameters of the application so that it generates malicious output. We find an XSS vulnerability when the application does not validate our input and creates an output that is under our control. This vulnerability leads to various attacks, for example, stealing confidential information (such as session cookies) or taking control of the victim's browser. An XSS attack breaks the following pattern: Input -> Output == cross-site scripting
In this guide, the following types of XSS testing are discussed in details:
1. Testing for Reflected Cross Site Scripting
A black-box test will include at least three phases:
1. Detect input vectors. The tester must determine the web application’s variables and how to input them in the web
application. See the example below.
2. Analyze each input vector to detect potential vulnerabilities. To detect an XSS vulnerability, the tester will typically use
specially crafted input data with each input vector. Such input data is typically harmless, but trigger responses from the web
browser that manifests the vulnerability. Testing data can be generated by using a web application fuzzer or manually.
3. For each vulnerability reported in the previous phase, the tester will analyze the report and attempt to exploit it with an
attack that has a realistic impact on the web application’s security.
Result :
i’m try to use mimmoo as user
http://www.akakom.ac.id/index.php?user=mimmoo
this is not works, but the web does not give any response. (eg message failed / message successful)
then i’m try to to insert a script in the url :
http://www.akakom.ac.id/index.php?user=<script>alert(123)</script>//
but after that url instead turned into:
http://www.akakom.ac.id/index.php?user=%20script%3EALERT%20123%20%20%2Fscript%3E#06346854087064835493
2. Testing for Stored Cross Site Scripting
because I can not log on and always fail to register as a user, then I insert scripts for Stored XSS. but the results do not exist, the web does not respond to the script that I paste.
alert(document.cookie)
3. Testing for DOM based Cross Site Scripting
DOM-based Cross-Site Scripting is the de-facto name for XSS bugs which are the result of active content on a page, typically JavaScript, obtaining user input and then doing something unsafe with it to lead to an XSS bug. This document will only discuss JavaScript bugs which lead to XSS.
Blackbox testing :
Blackbox testing for DOM-Based XSS is not usually performed since access to the source code is always available, as it needs to be sent to the client to be executed.
4. Testing for Cross Site Flashin
ActionScript is the language, based on ECMAScript, used by Flash applications when dealing with interactive needs. ActionScript, like every other language, has some implementation patterns which could lead to security issues. In particular, since Flash applications are often embedded in browsers, vulnerabilities like DOM based Cross Site Scripting
could be present in flawed Flash applications.
5. SQL Injection
In SQL injection testing, we test if it is possible to inject data into the application so that it executes a user-controlled SQL query in the back-end DB. We find a SQL injection vulnerability if the application uses user input to create SQL queries without proper input validation. A successful exploitation of this class of vulnerability allows an unauthorized user to access or manipulate data in the database. Note that application data often represents the core asset of a company. A SQL Injection attack breaks the following pattern: Input -> Query SQL == SQL injection
SQL Injection testing is further broken down into:
1. Oracle Testing
2. MySQL Testing
3. SQL Server Testing
4. MS Access Testing
5. Testing PostgreSQL
In SQL injection testing, we test if it is possible to inject data into the application so that it executes a user-controlled SQL query in the back-end DB. We find a SQL injection vulnerability if the application uses user input to create SQL queries without proper input validation.
i’m try to :
username = 1′ or ’1′ = ’1
password = 1′ or ’1′ = ’1
but still failed
6. LDAP Injection
LDAP injection testing is similar to SQL Injection testing. The differences are that we use the LDAP protocol instead of SQL and that the target is an LDAP Server instead of a SQL Server. An LDAP Injection attack breaks the following pattern: Input -> Query LDAP == LDAP injection
Blackbox testing :
http://www.akakom.ac.id/ldapsearch?user=*
7. ORM Injection
ORM injection testing is similar to SQL Injection Testing, as well. In this case, we use a SQL Injection against an ORMgenerated data access object model. From the tester’s point of view, this attack is virtually identical to a SQL Injection attack. However, the injection vulnerability exists in the code generated by an ORM tool.
Black box
Black box testing for ORM Injection vulnerabilities is identical to SQL Injection testing (see Testing for SQL_Injection.) In most cases, the vulnerability in the ORM layer is a result of customized code that does not properly validate input parameters. Most ORM software provides safe functions to escape user input. However if these functions are not used, and the developer uses custom functions that accept user input, it may be possible to execute a SQL injection attack.
8. XML Injectio
In XML injection testing, we test if it possible to inject a particular XML document into the application. We find an XML injection vulnerability if the XML parser fails to make appropriate data validation.
An XML Injection attack breaks the following pattern:
Input -> XML doc == XML injection
Blacbox testing
When a user register himself by filling an HTML form, the application will receive the user’s data in a standard request, which for the sake of simplicity will be supposed to be sent as a GET request.
http://www.akakom.ac.id/addUser.php?username=mimmoo&password=18181818&email=ssbella18@gmail.com
but its not works
9. SSI Injection
Web servers usually give developers the ability to add small pieces of dynamic code inside static HTML pages, without having to deal with full-fledged server-side or client-side languages. This feature is incarnated by Server-Side Includes (SSI) Injection. In SSI injection testing, we test if it is possible to inject into the application data that will be interpreted by SSI mechanisms. A successful exploitation of this vulnerability allows an attacker to inject code into HTML pages or even perform remote code execution.
10. XPath Injection
XPath is a language that has been designed and developed primarily to address parts of an XML document. In XPath injection testing, we test if it is possible to inject data into an application so that it executes user-controlled XPath queries. When successfully exploited, this vulnerability may allow an attacker to bypass authentication mechanisms or access information without proper authorization
11. IMAP/SMTP Injection
This threat affects all the applications that communicate with mail servers (IMAP/SMTP), generally webmail applications. In IMAP/SMTP injection testing, we test if it possible to inject arbitrary IMAP/SMTP commands into the mail servers, due to input data not properly sanitized. An IMAP/SMTP Injection attack breaks the following pattern:
Input -> IMAP/SMTP command == IMAP/SMTP Injection
12. Code Injection
In code injection testing, we check if it is possible to inject into an application data that will be later executed by the web server. A Code Injection attack breaks the following pattern:
Input -> malicious Code == Code Injection
13. OS Commanding
In command injection testing, we will try to inject an OS command through an HTTP request into the application. An OS Command Injection attack breaks the following pattern:
Input -> OS Command == OS Command Injection
Black box testing :
http://www.akakom.ac.id/cgi-bin/userData.pl?doc=user1.txt
14. Buffer overflow
In these tests, we check for different types of buffer overflow vulnerabilities. Here are the testing methods for the common
types of buffer overflow vulnerabilities:
1. Heap overflow
2.Stack overflow
3. Format string
In general Buffer overflow breaks the following pattern:
Input -> Fixed buffer or format string == overflow
15. Incubated vulnerability Testing
Incubated testing is a complex testing that needs more than one data validation vulnerability to work. In every pattern shown, the data should be validated by the application before it's trusted and processed. The goal of our testing is to verify if the application actually performs validation and does not trust its input.
16. Testing for HTTP Spltting/Smuggling
Describes how to test for an HTTP Exploit, as HTTP Verb, HTTP Splitting, HTTP Smuggling.
Comments
Post a Comment