Testing for IMAP/SMTP Injection (OTG-INPVAL-011) - Revision history

Andrew Muller: Andrew Muller moved page Testing for IMAP/SMTP Injection (OTG-INPVAL-012) to Testing for IMAP/SMTP Injection (OTG-INPVAL-011)

2014-08-08T12:04:09Z

Andrew Muller moved page Testing for IMAP/SMTP Injection (OTG-INPVAL-012) to Testing for IMAP/SMTP Injection (OTG-INPVAL-011)

Andrew Muller at 16:18, 31 July 2014

2014-07-31T16:18:30Z

Andrew Muller: Andrew Muller moved page Testing for IMAP/SMTP Injection (OWASP-DV-011) to Testing for IMAP/SMTP Injection (OTG-INPVAL-012): Align with Common Numbering

2014-07-31T14:36:42Z

Andrew Muller moved page Testing for IMAP/SMTP Injection (OWASP-DV-011) to Testing for IMAP/SMTP Injection (OTG-INPVAL-012): Align with Common Numbering

Jane O'Connor: Final edit

2014-05-19T10:16:02Z

Final edit

Show changes

Mmeucci at 14:52, 9 October 2012

2012-10-09T14:52:33Z

KirstenS: /* Brief Summary */

2009-02-09T13:23:03Z

‎Brief Summary

Runestone: correcting typo

2009-01-30T09:38:00Z

correcting typo

KirstenS: Testing for IMAP/SMTP Injection moved to Testing for IMAP/SMTP Injection (OWASP-DV-011)

2008-12-15T21:48:44Z

Testing for IMAP/SMTP Injection moved to Testing for IMAP/SMTP Injection (OWASP-DV-011)

KirstenS: /* Black Box testing and example */

2008-12-14T01:50:31Z

‎Black Box testing and example

KirstenS: /* Brief Summary */

2008-12-14T01:46:39Z

‎Brief Summary

@@ Line 1: / Line 1: @@
 {{Template:OWASP Testing Guide v4}}
-== Brief Summary ==
+== Summary ==
 This threat affects all applications that communicate with mail servers (IMAP/SMTP), generally webmail applications. The aim of this test is to verify the capacity to inject arbitrary IMAP/SMTP commands into the mail servers, due to input data not being properly sanitized.
-==Description of the Issue==
+The IMAP/SMTP Injection technique is more effective if the mail server is not directly accessible from Internet. Where full communication with the backend mail server is possible, it is recommended to conduct direct testing.
@@ Line 29: / Line 28: @@
-== Black Box testing and example ==
+== How to Test ==
 The standard attack patterns are:
 * Identifying vulnerable parameters
@@ Line 36: / Line 35: @@
-'''Identifying vulnerable parameters'''
+===Identifying vulnerable parameters===
 In order to detect vulnerable parameters, the tester has to analyze the application's ability in handling input. Input validation testing requires the tester to send bogus, or malicious, requests to the server and analyse the response. In a secure application, the response should be an error with some corresponding action telling the client that something has gone wrong. In a vulnerable application, the malicious request may be processed by the back-end application that will answer with a "HTTP 200 OK" response message.
@@ Line 132: / Line 131: @@
 <br>
-'''Understanding the data flow and deployment structure of the client'''
+===Understanding the data flow and deployment structure of the client===
-----
 After identifying all vulnerable parameters (for example, "passed_id"), the tester needs to determine what level of injection is possible and then design a testing plan to further exploit the application.
@@ Line 169: / Line 168: @@
 <br>
-'''IMAP/SMTP command injection'''
+===IMAP/SMTP command injection===
-----
 Once the tester has identified vulnerable parameters and has analyzed the context in which they are executed, the next stage is exploiting the functionality.

← Older revision		Revision as of 14:52, 9 October 2012
Line 1:		Line 1:
−	{{Template:OWASP Testing Guide v3}}	+	{{Template:OWASP Testing Guide v4}}

	== Brief Summary ==		== Brief Summary ==

@@ Line 2: / Line 2: @@
 == Brief Summary ==
-This threat affects all applications that communicate with mail servers (IMAP/SMTP), generally webmail applications. The aim of this test is to verify the capacity to inject arbitrary IMAP/SMTP commands into the mail servers, due to input data not properly sanitized.
+This threat affects all applications that communicate with mail servers (IMAP/SMTP), generally webmail applications. The aim of this test is to verify the capacity to inject arbitrary IMAP/SMTP commands into the mail servers, due to input data not being properly sanitized.
 ==Description of the Issue==

@@ Line 13: / Line 13: @@
 Figure 1 - Communication with the mail servers using the IMAP/SMTP Injection technique.</center><br>
-Figure 1 depicts the flow of traffic generally seen when using webmail technologies. Step 1 and 2 is the user interacting with the webmail client, whereas step 2' is the tester bypassing the webmail client and interacting with the back-end mail servers directly.
+Figure 1 depicts the flow of traffic generally seen when using webmail technologies. Step 1 and 2 is the user interacting with the webmail client, whereas step 2 is the tester bypassing the webmail client and interacting with the back-end mail servers directly.
 This technique allows a wide variety of actions and attacks. The possibilities depend on the type and scope of injection and the mail server technology being tested.

@@ Line 25: / Line 25: @@
 == Black Box testing and example ==
-The standard attacks pattern are:
+The standard attack patterns are:
 * Identifying vulnerable parameters
 * Understanding the data flow and deployment structure of the client
@@ Line 34: / Line 34: @@
 In order to detect vulnerable parameters, the tester has to analyze the application's ability in handling input. Input validation testing requires the tester to send bogus, or malicious, requests to the server and analyse the response. In a secure application, the response should be an error with some corresponding action telling the client that something has gone wrong. In a vulnerable application, the malicious request may be processed by the back-end application that will answer with a "HTTP 200 OK" response message.
-It is important to notice that the requests being sent should match the technology being tested. Sending SQL injection strings for Microsoft SQL server when a MySQL server is being used will result in false positive responses. In this case, sending malicious IMAP commands is modus operandi since IMAP is the underlying protocol being tested.
+It is important to note that the requests being sent should match the technology being tested. Sending SQL injection strings for Microsoft SQL server when a MySQL server is being used will result in false positive responses. In this case, sending malicious IMAP commands is modus operandi since IMAP is the underlying protocol being tested.
 IMAP special parameters that should be used are:
@@ Line 88: / Line 88: @@
 Situations S1 and S2 represent successful IMAP/SMTP injection.
-An attacker's aim is receiving the S1 response as it is an indicator that the application is vulnerable to injection and further manipulation.
+An attacker's aim is receiving the S1 response, as it is an indicator that the application is vulnerable to injection and further manipulation.
 Let's suppose that a user retrieves the email headers using the following HTTP request:
@@ Line 118: / Line 118: @@
 '''Understanding the data flow and deployment structure of the client'''
 ----
-After having identifying all vulnerable parameters (for example, "passed_id"), the tester needs to determine what level of injection is possible and then design a testing plan to further exploit the application.
+After identifying all vulnerable parameters (for example, "passed_id"), the tester needs to determine what level of injection is possible and then design a testing plan to further exploit the application.
@@ Line 150: / Line 150: @@
 '''IMAP/SMTP command injection'''
 ----
-Once the tester has identified vulnerable parameters and has analyzed the context in which it is executed, the next stage is exploiting the functionality.
+Once the tester has identified vulnerable parameters and has analyzed the context in which they are executed, the next stage is exploiting the functionality.
 This stage has two possible outcomes:<br>
-. The injection is possible in an unauthenticated state: the affected functionality does not require the user to be authenticated. The injected (IMAP) commands available are limited to: CAPABILITY, NOOP, AUTHENTICATE, LOGIN and LOGOUT.<br>
+. The injection is possible in an unauthenticated state: the affected functionality does not require the user to be authenticated. The injected (IMAP) commands available are limited to: CAPABILITY, NOOP, AUTHENTICATE, LOGIN, and LOGOUT.<br>
 . The injection is only possible in an authenticated state: the successful exploitation requires the user to be fully authenticated before testing can continue.

← Older revision	Revision as of 12:04, 8 August 2014
(No difference)

← Older revision	Revision as of 14:36, 31 July 2014
(No difference)

← Older revision	Revision as of 21:48, 15 December 2008
(No difference)