ZAP by Checkmarx Scanning Report

Generated with The ZAP logoZAP on Fri 1 Nov 2024, at 23:31:42

ZAP Version: 2.15.0

ZAP by Checkmarx

Contents
1. About this report
1. Report parameters
2. Summaries
1. Alert counts by risk and confidence
2. Alert counts by site and risk
3. Alert counts by alert type
3. Alerts
1. Risk=High, Confidence=Medium (5)
2. Risk=Medium, Confidence=Medium (1)
3. Risk=Informational, Confidence=High (1)
4. Risk=Informational, Confidence=Medium (1)
4. Appendix
1. Alert types

About this report

Report parameters

Contexts

No contexts were selected, so all contexts were included by default.

Sites

The following sites were included:

https://scanpick.in
http://testphp.vulnweb.com

(If no sites were selected, all sites were included by default.)

An included site must also be within one of the included contexts for its data to be included in the report.

Risk levels

Included: High, Medium, Low, Informational

Excluded: None

Confidence levels

Included: User Confirmed, High, Medium, Low

Excluded: User Confirmed, High, Medium, Low, False Positive

Summaries
Alert counts by risk and confidence

This table shows the number of alerts for each level of risk and confidence included in the report.

(The percentages in brackets represent the count as a percentage of the total number of alerts included in the report, rounded to
one decimal place.)

Confidence
User Confirmed High Medium Low Total
0 0 5 0 5
High
(0.0%) (0.0%) (62.5%) (0.0%) (62.5%)
0 0 1 0 1
Medium
(0.0%) (0.0%) (12.5%) (0.0%) (12.5%)
0 0 0 0 0
Risk Low
(0.0%) (0.0%) (0.0%) (0.0%) (0.0%)
0 1 1 0 2
Informational
(0.0%) (12.5%) (12.5%) (0.0%) (25.0%)
0 1 7 0 8
Total
(0.0%) (12.5%) (87.5%) (0.0%) (100%)

Alert counts by site and risk

This table shows, for each site for which one or more alerts were raised, the number of alerts raised at each risk level.

Alerts with a confidence level of "False Positive" have been excluded from these counts.

(The numbers in brackets are the number of alerts raised for the site at or above that risk level.)

Risk
High Medium Low Informational
(= High) (>= Medium) (>= Low) (>= Informational)
5 1 0 2
Site http://testphp.vulnweb.com
(5) (6) (6) (8)

Alert counts by alert type

This table shows the number of alerts of each alert type, together
with the alert type's risk level.

(The percentages in brackets represent each count as a

percentage, rounded to one decimal place, of the total number of
alerts included in this report.)

Alert type Risk

Count
12
Cross Site Scripting (Reflected) High
(150.0%)
5
SQL Injection High
(62.5%)
4
SQL Injection - MySQL High
(50.0%)
1
SQL Injection - Oracle - Time Based High
(12.5%)
1
SQL Injection - SQLite High
(12.5%)
2
XSLT Injection Medium
(25.0%)
3
GET for POST Informational
(37.5%)
197
User Agent Fuzzer Informational
(2,462.5%)
Total 8

Alerts
1. Risk=High, Confidence=Medium (5)

1. http://testphp.vulnweb.com (5)

1. Cross Site Scripting (Reflected) (1)

1. POST http://testphp.vulnweb.com/secured/newuser.php

2. SQL Injection (1)

1. POST http://testphp.vulnweb.com/userinfo.php

3. SQL Injection - MySQL (1)

1. POST http://testphp.vulnweb.com/secured/newuser.php

4. SQL Injection - Oracle - Time Based (1)

1. POST http://testphp.vulnweb.com/secured/newuser.php

5. SQL Injection - SQLite (1)

1. POST http://testphp.vulnweb.com/secured/newuser.php

2. Risk=Medium, Confidence=Medium (1)

1. http://testphp.vulnweb.com (1)

1. XSLT Injection (1)

1. GET http://testphp.vulnweb.com/showimage.php?file=%3Cxsl%3Avalue-of+select%3D%22document%28%27http%3A%2F%2Ftestphp.vulnweb.com%3A22%27%29%22%2F%3E&size=160

3. Risk=Informational, Confidence=High (1)

1. http://testphp.vulnweb.com (1)

1. GET for POST (1)

1. GET http://testphp.vulnweb.com/cart.php

4. Risk=Informational, Confidence=Medium (1)

1. http://testphp.vulnweb.com (1)

1. User Agent Fuzzer (1)

1. POST http://testphp.vulnweb.com/guestbook.php

Appendix
Alert types
This section contains additional information on the types of alerts in the report.

1. Cross Site Scripting (Reflected)

Source raised by an active scanner (Cross Site Scripting (Reflected))

CWE ID 79
WASC ID 8
1. https://owasp.org/www-community/attacks/xss/
Reference
2. https://cwe.mitre.org/data/definitions/79.html

2. SQL Injection

Source raised by an active scanner (SQL Injection)

CWE ID 89
WASC ID 19
Reference 1. https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

3. SQL Injection - MySQL

Source raised by an active scanner (SQL Injection)

CWE ID 89
WASC ID 19
Reference 1. https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

4. SQL Injection - Oracle - Time Based

Source raised by an active scanner (SQL Injection - Oracle)

CWE ID 89
WASC ID 19
Reference 1. https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

5. SQL Injection - SQLite

Source raised by an active scanner (SQL Injection - SQLite)

CWE ID 89
WASC ID 19
Reference 1. https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

6. XSLT Injection

Source raised by an active scanner (XSLT Injection)

CWE ID 91
WASC ID 23
Reference 1. https://www.contextis.com/blog/xslt-server-side-injection-attacks

7. GET for POST

Source raised by an active scanner (GET for POST)

CWE ID 16
WASC ID 20

8. User Agent Fuzzer

Source raised by an active scanner (User Agent Fuzzer)

Reference 1. https://owasp.org/wstg
Phase: Architecture and Design

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.

Consult the XSS Prevention Cheat Sheet for more details on the types of encoding and escaping that are
needed.

Phase: Architecture and Design

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.

If available, use structured mechanisms that automatically enforce the separation between data and code.
These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically,
instead of relying on the developer to provide this capability at every point where output is generated.

Phase: Implementation

For every web page that is generated, use and specify a 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 cause the web browser to treat certain sequences
as special, opening up the client to subtle XSS attacks. See CWE-116 for more mitigations related to
encoding/escaping.

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.

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use an allow list 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 deny list). However, deny lists 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."

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.

Do not trust client side input, even if there is client side validation in place.

In general, type check all data on the server side.

If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?'

If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries.

If database Stored Procedures can be used, use them.

Do *not* concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or
equivalent functionality!

Do not create dynamic SQL queries using simple string concatenation.

Escape all data received from the client.

Apply an 'allow list' of allowed characters, or a 'deny list' of disallowed characters in user input.

Apply the principle of least privilege by using the least privileged database user possible.

In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but
minimizes its impact.

Grant the minimum database access that is necessary for the application.