This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Cornucopia - Ecommerce Website - VE 2"

From OWASP
Jump to: navigation, search
(New page)
 
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[File:VE_2.png|200px|thumb|right]]
+
{{DISPLAYTITLE:<span style="padding:2px 5px 0px 5px;color:white;background:#929292;">Cornucopia - Ecommerce Website - VE 2</span>}}
'''Category:''' Data Validation and Encoding
+
[[File:Cornucopia_-_Ecommerce_Website_VE_2.png|frame|right]]
 +
'''Suit:''' [[Cornucopia_-_Ecommerce_Website_-_VE|Data Validation and Encoding]]
  
'''Value:''' 2
+
'''Card/Value:''' 2
  
 
=== Description: ===
 
=== Description: ===
Line 8: Line 9:
 
Brian can gather information about the underlying configurations, schemas, logic, code, software, services and infrastructure due to the content of error messages, or poor configuration, or the presence of default installation files or old, test, backup or copies of resources, or exposure of source code.
 
Brian can gather information about the underlying configurations, schemas, logic, code, software, services and infrastructure due to the content of error messages, or poor configuration, or the presence of default installation files or old, test, backup or copies of resources, or exposure of source code.
  
=== Technical note: ===
+
=== Technical Note: ===
  
Many webservers (and other base software) usually provide error messages with information about the nature of the error by default. This is most useful to the developer, as it helps to identify where the error is happening and why. They also provide some admin functions by default to ease their learning curve start. However, if this default behaviour is not changed, users (and attackers) can profit from it to adquire knowledge about the internal workings of the application.
+
Many ecommerce webservers (and other base software) usually provide error messages with information about the nature of the error by default. This is most useful to the developer, as it helps to identify where the error is happening and why. The default configuration also sometimes provides some admin functions to ease their learning curve. However, if this default behaviour is not changed in non-development environments, users (and attackers) can profit from it to acquire knowledge about the internal workings of the application and supporting systems/components.
  
Other sources of information disclosure are often generated by the developer. This goes from messages for internal use (that are not removed when sent to production) to simple bad programming practices. Some examples of these are:   
+
Other sources of information disclosure are often generated by the developer. These range from messages for internal use, and are not removed when deployed in production, to simple bad programming practices. Some examples of these are:   
  
* Exposing sensitive information (such as session identifiers, variables references, login data, etc.) in URLs, custom error messages, comments or logs.
+
* Exposing sensitive information (such as session identifiers, variables references, login data, etc.) in HTTP headers, URLs, custom error messages, comments, logs, related email messages, etc.
* Revealing the application OS structure (path to files in error messages or misuse of the robots.txt file).
+
* Including server-side source code in outputs accessible by users.
* Giving hints about the application workflow and/or security checks as user friendly messages (e.g. using different messages at the user login page to indicate that the username or the password are wrong).
+
* Including sensitive comments in outputs accessible by users.
 +
* Allowing user access to configuration files.
 +
* Leaving default install, unused or old files in web accessible locations.
 +
* Revealing the application file structure (path to files in error messages or misuse of the robots.txt file).
 +
* Giving hints about the application workflow and/or security checks as user friendly messages.
 +
 
 +
See Authentication [[Cornucopia_-_Ecommerce_Website_-_AT_7|AT 7]] relating to different messages at the user login page to indicate that the username or the password are wrong.
  
 
=== References: ===
 
=== References: ===
  
 
<table class="wikitable" style="text-align:center;">
 
<table class="wikitable" style="text-align:center;">
<tr><th>OWASP SCP </th><th>OWASP ASVS </th><th>OWASP AppSensor</th><th>CAPEC </th><th>SAFECode</th></tr>
+
 
  <tr><td><span title="Session Management">[[OWASP_Secure_Coding_Practices_Checklist_v2#69|69]]</span></td><td><span title="Access Control Verification Requirements">[[OWASP_Application_Security_Verification_Standard#4.5|4.5]]</span></td><td><span title="Honey Trap">[[OWASP_AppSensor_DetectionPoints#HT1|HT1]]</span></td><td><span title=" ">[https://capec.mitre.org/data/definitions/54.html 54]</span></td><td><span title=" ">[[SAFECode_Practical_Security_Stories#4|4]]</span></td></tr>
+
<tr>
  <tr><td><span title="Error Handling and Logging">[[OWASP_Secure_Coding_Practices_Checklist_v2#107|107]]</span></td><td><span title="Error Handling and Logging Verification Requirements">[[OWASP_Application_Security_Verification_Standard#8.1|8.1]]</span></td><td><span title="Honey Trap">[[OWASP_AppSensor_DetectionPoints#HT2|HT2]]</span></td><td><span title=" ">[https://capec.mitre.org/data/definitions/224.html 224]</span></td><td><span title=" ">[[SAFECode_Practical_Security_Stories#23|23]]</span></td></tr>
+
<th>OWASP SCP </th>
  <tr><td><span title="Error Handling and Logging">[[OWASP_Secure_Coding_Practices_Checklist_v2#108|108]]</span></td><td><span title="Error Handling and Logging Verification Requirements">[[OWASP_Application_Security_Verification_Standard#8.2|8.2]]</span></td><td><span title="Honey Trap">[[OWASP_AppSensor_DetectionPoints#HT3|HT3]]</span></td><td> </td><td> </td></tr>
+
<th>OWASP ASVS </th>
  <tr><td><span title="Error Handling and Logging">[[OWASP_Secure_Coding_Practices_Checklist_v2#109|109]]</span></td><td> </td><td> </td><td> </td><td> </td></tr>
+
<th>OWASP AppSensor</th>
  <tr><td><span title="Error Handling and Logging">[[OWASP_Secure_Coding_Practices_Checklist_v2#136|136]]</span></td><td> </td><td> </td><td> </td><td> </td></tr>
+
<th>CAPEC </th>
  <tr><td><span title="Error Handling and Logging">[[OWASP_Secure_Coding_Practices_Checklist_v2#137|137]]</span></td><td> </td><td> </td><td> </td><td> </td></tr>
+
<th>SAFECode</th>
  <tr><td><span title="System Configuration">[[OWASP_Secure_Coding_Practices_Checklist_v2#153|153]]</span></td><td> </td><td> </td><td> </td><td> </td></tr>
+
</tr>
  <tr><td><span title="System Configuration">[[OWASP_Secure_Coding_Practices_Checklist_v2#156|156]]</span></td><td> </td><td> </td><td> </td><td> </td></tr>
+
   
  <tr><td><span title="System Configuration">[[OWASP_Secure_Coding_Practices_Checklist_v2#158|158]]</span></td><td> </td><td> </td><td> </td><td> </td></tr>
+
<tr>
  <tr><td><span title="System Configuration">[[OWASP_Secure_Coding_Practices_Checklist_v2#162|162]]</span></td><td> </td><td> </td><td> </td><td></td></tr>
+
<td>[[OWASP_Secure_Coding_Practices_Checklist#69|69]]</td>
 +
<td>[[OWASP_Application_Security_Verification_Standard#4.5|4.5]]</td>
 +
<td>[[AppSensor_DetectionPoints#HT1|HT1]]</td>
 +
<td>[https://capec.mitre.org/data/definitions/54.html 54]</td>
 +
<td>[[SAFECode_Practical_Security_Stories#4|4]]</td>
 +
</tr>
 +
   
 +
<tr>
 +
<td>[[OWASP_Secure_Coding_Practices_Checklist#107|107]]</td>
 +
<td>[[OWASP_Application_Security_Verification_Standard#8.1|8.1]]</td>
 +
<td>[[AppSensor_DetectionPoints#HT2|HT2]]</td>
 +
<td>[https://capec.mitre.org/data/definitions/224.html 224]</td>
 +
<td>[[SAFECode_Practical_Security_Stories#23|23]]</td>
 +
</tr>
 +
   
 +
<tr>
 +
<td>[[OWASP_Secure_Coding_Practices_Checklist#108|108]]</td>
 +
<td>[[OWASP_Application_Security_Verification_Standard#8.2|8.2]]</td>
 +
<td>[[AppSensor_DetectionPoints#HT3|HT3]]</td>
 +
<td> </td>
 +
<td> </td>
 +
</tr>
 +
   
 +
<tr>
 +
<td>[[OWASP_Secure_Coding_Practices_Checklist#109|109]]</td>
 +
<td> </td>
 +
<td> </td>
 +
<td> </td>
 +
<td> </td>
 +
</tr>
 +
   
 +
<tr>
 +
<td>[[OWASP_Secure_Coding_Practices_Checklist#136|136]]</td>
 +
<td> </td>
 +
<td> </td>
 +
<td> </td>
 +
<td> </td>
 +
</tr>
 +
   
 +
<tr>
 +
<td>[[OWASP_Secure_Coding_Practices_Checklist#137|137]]</td>
 +
<td> </td>
 +
<td> </td>
 +
<td> </td>
 +
<td> </td>
 +
</tr>
 +
   
 +
<tr>
 +
<td>[[OWASP_Secure_Coding_Practices_Checklist#153|153]]</td>
 +
<td> </td>
 +
<td> </td>
 +
<td> </td>
 +
<td> </td>
 +
</tr>
 +
   
 +
<tr>
 +
<td>[[OWASP_Secure_Coding_Practices_Checklist#156|156]]</td>
 +
<td> </td>
 +
<td> </td>
 +
<td> </td>
 +
<td> </td>
 +
</tr>
 +
   
 +
<tr>
 +
<td>[[OWASP_Secure_Coding_Practices_Checklist#158|158]]</td>
 +
<td> </td>
 +
<td> </td>
 +
<td> </td>
 +
<td> </td>
 +
</tr>
 +
   
 +
<tr>
 +
<td>[[OWASP_Secure_Coding_Practices_Checklist#162|162]]</td>
 +
<td> </td>
 +
<td> </td>
 +
<td> </td>
 +
<td></td>
 +
</tr>
 
</table>
 
</table>
 +
 +
 +
<div style="padding:5px;background:LightGray;color:White;font-weight:bold;">[[Cornucopia_-_Ecommerce_Website_-_W_Joker_B|« Previous Card]] <span style="padding-left:10px;padding-right:10px;">|</span>  [[Cornucopia_-_Ecommerce_Website_-_VE|Data Validation and Encoding]] <span style="padding-left:10px;padding-right:10px;">|</span> [[Cornucopia_-_Ecommerce_Website_-_VE_3|Next Card »]] </div>

Latest revision as of 14:06, 21 January 2016

Cornucopia - Ecommerce Website VE 2.png

Suit: Data Validation and Encoding

Card/Value: 2

Description:

Brian can gather information about the underlying configurations, schemas, logic, code, software, services and infrastructure due to the content of error messages, or poor configuration, or the presence of default installation files or old, test, backup or copies of resources, or exposure of source code.

Technical Note:

Many ecommerce webservers (and other base software) usually provide error messages with information about the nature of the error by default. This is most useful to the developer, as it helps to identify where the error is happening and why. The default configuration also sometimes provides some admin functions to ease their learning curve. However, if this default behaviour is not changed in non-development environments, users (and attackers) can profit from it to acquire knowledge about the internal workings of the application and supporting systems/components.

Other sources of information disclosure are often generated by the developer. These range from messages for internal use, and are not removed when deployed in production, to simple bad programming practices. Some examples of these are:

  • Exposing sensitive information (such as session identifiers, variables references, login data, etc.) in HTTP headers, URLs, custom error messages, comments, logs, related email messages, etc.
  • Including server-side source code in outputs accessible by users.
  • Including sensitive comments in outputs accessible by users.
  • Allowing user access to configuration files.
  • Leaving default install, unused or old files in web accessible locations.
  • Revealing the application file structure (path to files in error messages or misuse of the robots.txt file).
  • Giving hints about the application workflow and/or security checks as user friendly messages.

See Authentication AT 7 relating to different messages at the user login page to indicate that the username or the password are wrong.

References:

OWASP SCP OWASP ASVS OWASP AppSensor CAPEC SAFECode
69 4.5 HT1 54 4
107 8.1 HT2 224 23
108 8.2 HT3
109
136
137
153
156
158
162


« Previous Card | Data Validation and Encoding | Next Card »