diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000000000000000000000000000000000000..10da2a6fb54c2cfeeb755a1e6aecd1284814f90f
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,106 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+env/
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+
+# PyInstaller
+# Usually these files are written by a python script from a template
+# before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+.hypothesis/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# pyenv
+.python-version
+
+# celery beat schedule file
+celerybeat-schedule
+
+# SageMath parsed files
+*.sage.py
+
+# dotenv
+.env
+
+# virtualenv
+.venv
+venv/
+ENV/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+
+# Config file
+config/config.json
+
+test.py
diff --git a/README.rst b/README.rst
index 6eba3705bcaab79fe72afb7b0199007032668086..994b38221defede71ebcbaca7c76a677d42a8738 100644
--- a/README.rst
+++ b/README.rst
@@ -13,6 +13,7 @@ Several quick start options are available:
- Install with pip (recommended): :code:`pip install defectdojo_api`
- `Download the latest release <https://github.com/aaronweaver/defectdojo_api/releases/latest>`_
- Clone the repository: :code:`git clone https://github.com/aaronweaver/defectdojo_api`
+- If you are testing the api locally make sure to set the PYTHONPATH. export PYTHONPATH=/path/totheapi/defectdojo_api:$PYTHONPATH
Example
-------
diff --git a/defectdojo_api/__init__.py b/defectdojo_api/__init__.py
index 10939f01be01b705d43126b5a824a2017c2c46a5..1f356cc57bfa00a3b251402604c54702fb414c96 100644
--- a/defectdojo_api/__init__.py
+++ b/defectdojo_api/__init__.py
@@ -1 +1 @@
-__version__ = '0.1.2'
+__version__ = '1.0.0'
diff --git a/defectdojo_api/__init__.pyc b/defectdojo_api/__init__.pyc
new file mode 100644
index 0000000000000000000000000000000000000000..9b3663b1192b6aeeddfdb776439a94a1091fb937
Binary files /dev/null and b/defectdojo_api/__init__.pyc differ
diff --git a/defectdojo_api/defectdojo.py b/defectdojo_api/defectdojo.py
index 830389dd1216ede7eb6e596912c45b301fed15fb..a9d68edc76e8d3e42dcf893cef5032c482480b94 100644
--- a/defectdojo_api/defectdojo.py
+++ b/defectdojo_api/defectdojo.py
@@ -153,9 +153,9 @@ class DefectDojoAPI(object):
"""
return self._request('GET', 'engagements/' + str(engagement_id) + '/')
- def create_engagement(self, name, product_id, lead_id, status, target_start, target_end, active='true',
- pen_test='false', check_list='false', threat_model='false', risk_path="", test_strategy="", progress="",
- done_testing=""):
+ def create_engagement(self, name, product_id, lead_id, status, target_start, target_end, active='True',
+ pen_test='False', check_list='False', threat_model='False', risk_path="", test_strategy="", progress="",
+ done_testing='False'):
"""Creates an engagement with the given properties.
:param name: Engagement name.
diff --git a/defectdojo_api/defectdojo.pyc b/defectdojo_api/defectdojo.pyc
new file mode 100644
index 0000000000000000000000000000000000000000..35ab2615cd920482745008bb444d8ed76ca9c94d
Binary files /dev/null and b/defectdojo_api/defectdojo.pyc differ
diff --git a/examples/.DS_Store b/examples/.DS_Store
new file mode 100644
index 0000000000000000000000000000000000000000..7810611dc74d792f9145620157eebed9f5024b63
Binary files /dev/null and b/examples/.DS_Store differ
diff --git a/examples/dojo_ci_cd.py b/examples/dojo_ci_cd.py
index 0e05d9acc029d53c39470ba7cdc495e0895ab108..8f6cfcacd87a537bcd42eb4ff38fe61a7741c617 100644
--- a/examples/dojo_ci_cd.py
+++ b/examples/dojo_ci_cd.py
@@ -6,126 +6,230 @@ Description: CI/CD example for DefectDojo
"""
from defectdojo_api import defectdojo
from datetime import datetime, timedelta
-import os
+import os, sys
import argparse
+import time
+import junit_xml_output
-DEBUG = False
+DEBUG = True
-def sum_severity(findings):
- severity = [0,0,0,0,0]
- for finding in findings.data["objects"]:
- if finding["severity"] == "Critical":
- severity[4] = severity[4] + 1
- if finding["severity"] == "High":
- severity[3] = severity[3] + 1
- if finding["severity"] == "Medium":
- severity[2] = severity[2] + 1
- if finding["severity"] == "Low":
- severity[1] = severity[1] + 1
- if finding["severity"] == "Info":
- severity[0] = severity[0] + 1
+test_cases = []
- return severity
+def junit(toolName, file):
-def print_findings(findings):
- print "Critical: " + str(findings[4])
- print "High: " + str(findings[3])
- print "Medium: " + str(findings[2])
- print "Low: " + str(findings[1])
- print "Info: " + str(findings[0])
-
-def create_findings(host, api_key, user, product_id, file, scanner, engagement_id=None, max_critical=0, max_high=0, max_medium=0, build=None):
+ junit_xml = junit_xml_output.JunitXml(toolName, test_cases, total_tests=None, total_failures=None)
+ with open(file, 'w') as file:
+ print "Writing Junit test files"
+ file.write(junit_xml.dump())
+def dojo_connection(host, api_key, user):
#Optionally, specify a proxy
proxies = {
- 'http': 'http://localhost:8080',
- 'https': 'http://localhost:8080',
+ 'http': 'http://localhost:8081',
+ 'https': 'http://localhost:8081',
}
- if DEBUG:
+ #if DEBUG:
# Instantiate the DefectDojo api wrapper
- dd = defectdojo.DefectDojoAPI(host, api_key, user, proxies=proxies, verify_ssl=False, timeout=360, debug=False)
- else:
- dd = defectdojo.DefectDojoAPI(host, api_key, user, verify_ssl=False, timeout=360, debug=False)
+ dd = defectdojo.DefectDojoAPI(host, api_key, user, proxies=proxies, verify_ssl=False, timeout=360, debug=False)
+ #else:
+ # dd = defectdojo.DefectDojoAPI(host, api_key, user, verify_ssl=False, timeout=360, debug=False)
+ return dd
# Workflow as follows:
# 1. Scan tool is run against build
# 2. Reports is saved from scan tool
# 3. Call this script to load scan data, specifying scanner type
# 4. Script returns along with a pass or fail results: Example: 2 new critical vulns, 1 low out of 10 vulnerabilities
+def return_engagement(dd, product_id):
#Specify the product id
product_id = product_id
- engagement_id = None
# Check for a CI/CD engagement_id
engagements = dd.list_engagements(product_in=product_id, status="In Progress")
+
if engagements.success:
for engagement in engagements.data["objects"]:
if "Recurring CI/CD Integration" == engagement['name']:
engagement_id = engagement['id']
- # Engagement doesn't exist, create it
if engagement_id == None:
start_date = datetime.now()
end_date = start_date+timedelta(days=180)
- users = dd.list_users("admin")
+ users = dd.list_users(user)
user_id = None
+
if users.success:
user_id = users.data["objects"][0]["id"]
- engagement_id = dd.create_engagement("Recurring CI/CD Integration", product_id, user_id,
+
+ engagement_id = dd.create_engagement("Recurring CI/CD Integration", product_id, str(user_id),
"In Progress", start_date.strftime("%Y-%m-%d"), end_date.strftime("%Y-%m-%d"))
+ return engagement_id
- # Upload the scanner export
- #dir_path = os.path.dirname(os.path.realpath(__file__))
+def process_findings(dd, engagement_id, dir, build=None):
+ test_ids = []
+ for root, dirs, files in os.walk(dir):
+ for name in files:
+ file = os.path.join(os.getcwd(),root, name)
+ test_id = processFiles(dd, engagement_id, file)
+ if test_id is not None:
+ test_ids.append(str(test_id))
+ return ','.join(test_ids)
- print "Uploading scanner data."
+def processFiles(dd, engagement_id, file, scanner=None, build=None):
+ upload_scan = None
+ scannerName = None
+ path=os.path.dirname(file)
+ name = os.path.basename(file)
+ tool = os.path.basename(path)
+ tool = tool.lower()
+
+ test_id = None
date = datetime.now()
- print scanner
- upload_scan = dd.upload_scan(engagement_id, scanner, file, "true", date.strftime("%Y-%m-%d"), build=build)
+ dojoDate = date.strftime("%Y-%m-%d")
- if upload_scan.success:
- test_id = upload_scan.id()
- else:
- print upload_scan.message
- quit()
-
- findings = dd.list_findings(engagement_id_in=engagement_id, duplicate="false", active="true", verified="true")
- print"=============================================="
- print "Total Number of Vulnerabilities: " + str(findings.data["meta"]["total_count"])
- print"=============================================="
- print_findings(sum_severity(findings))
- print
- findings = dd.list_findings(test_id_in=test_id, duplicate="true")
- print"=============================================="
- print "Total Number of Duplicate Findings: " + str(findings.data["meta"]["total_count"])
- print"=============================================="
- print_findings(sum_severity(findings))
- print
- findings = dd.list_findings(test_id_in=test_id, duplicate="false")
- print"=============================================="
- print "Total Number of New Findings: " + str(findings.data["meta"]["total_count"])
- print"=============================================="
- sum_new_findings = sum_severity(findings)
- print_findings(sum_new_findings)
- print
- print"=============================================="
-
- strFail = None
- if max_critical is not None:
- if sum_new_findings[4] > max_critical:
- strFail = "Build Failed: Max Critical"
- if max_high is not None:
- if sum_new_findings[3] > max_high:
- strFail = strFail + " Max High"
- if max_medium is not None:
- if sum_new_findings[2] > max_medium:
- strFail = strFail + " Max Medium"
- if strFail is None:
- print "Build Passed!"
+ #Tools without an importer in Dojo; attempted to import as generic
+ if "generic" in name:
+ scanner = "Generic Findings Import"
+ if tool == "nikto":
+ print "Uploading nikto scan: " + file
+ test_id = dd.upload_scan(engagement_id, scanner, file, "true", dojoDate, build)
+ elif tool == "bandit":
+ print "Uploading bandit scan: " + file
+ test_id = dd.upload_scan(engagement_id, scanner, file, "true", dojoDate, build)
else:
- print "Build Failed: " + strFail
- print"=============================================="
+ if tool == "burp":
+ scannerName = "Burp Scan"
+ elif tool == "nessus":
+ scannerName = "Nessus Scan"
+ elif tool == "nmap":
+ scannerName = "Nmap Scan"
+ elif tool == "nexpose":
+ scannerName = "Nexpose Scan"
+ elif tool == "veracode":
+ scannerName = "Veracode Scan"
+ elif tool == "checkmarx":
+ scannerName = "Checkmarx Scan"
+ elif tool == "zap":
+ scannerName = "ZAP Scan"
+ elif tool == "appspider":
+ scannerName = "AppSpider Scan"
+ elif tool == "Arachni Scan":
+ scannerName = "Arachni Scan"
+ elif tool == "vcg":
+ scannerName = "VCG Scan"
+ elif tool == "dependency":
+ scannerName = "Dependency Check Scan"
+ elif tool == "retirejs":
+ scannerName = "Retire.js Scan"
+ elif tool == "nodesecurity":
+ scannerName = "Node Security Platform Scan"
+ elif tool == "qualys":
+ scannerName = "Qualys Scan"
+ elif tool == "qualyswebapp":
+ scannerName = "Qualys Webapp Scan"
+ elif tool == "openvas":
+ scannerName = "OpenVAS CSV"
+ elif tool == "snyk":
+ scannerName = "Snyk Scan"
+
+ if scannerName is not None:
+ print "Uploading " + scannerName + " scan: " + file
+ test_id = dd.upload_scan(engagement_id, scannerName, file, "true", dojoDate, build)
+
+ return test_id
+ #print os.path.basename(full_path)
+
+def create_findings(dd, engagement_id, scanner, file, build=None):
+ # Upload the scanner export
+ if engagement_id > 0:
+ print "Uploading scanner data."
+ date = datetime.now()
+
+ upload_scan = dd.upload_scan(engagement_id, scanner, file, "true", date.strftime("%Y-%m-%d"), build=build)
+
+ if upload_scan.success:
+ test_id = upload_scan.id()
+ else:
+ print upload_scan.message
+ quit()
+
+def summary(dd, engagement_id, test_ids, max_critical=0, max_high=0, max_medium=0):
+ findings = dd.list_findings(engagement_id_in=engagement_id, duplicate="false", active="true", verified="true")
+ print"=============================================="
+ print "Total Number of Vulnerabilities: " + str(findings.data["meta"]["total_count"])
+ print"=============================================="
+ print_findings(sum_severity(findings))
+ print
+ findings = dd.list_findings(test_id_in=test_ids, duplicate="true")
+ print"=============================================="
+ print "Total Number of Duplicate Findings: " + str(findings.data["meta"]["total_count"])
+ print"=============================================="
+ print_findings(sum_severity(findings))
+ print
+ #Delay while de-dupes
+ sys.stdout.write("Sleeping for 30 seconds for de-dupe celery process:")
+ sys.stdout.flush()
+ for i in range(15):
+ time.sleep(2)
+ sys.stdout.write(".")
+ sys.stdout.flush()
+
+ findings = dd.list_findings(test_id_in=test_ids, duplicate="false", limit=500)
+ if findings.count() > 0:
+ for finding in findings.data["objects"]:
+ test_cases.append(junit_xml_output.TestCase(finding["title"] + " Severity: " + finding["severity"], finding["description"],"failure"))
+ if not os.path.exists("reports"):
+ os.mkdir("reports")
+ junit("DefectDojo", "reports/junit_dojo.xml")
+
+ print"\n=============================================="
+ print "Total Number of New Findings: " + str(findings.data["meta"]["total_count"])
+ print"=============================================="
+ sum_new_findings = sum_severity(findings)
+ print_findings(sum_new_findings)
+ print
+ print"=============================================="
+
+ strFail = ""
+ if max_critical is not None:
+ if sum_new_findings[4] > max_critical:
+ strFail = "Build Failed: Max Critical"
+ if max_high is not None:
+ if sum_new_findings[3] > max_high:
+ strFail = strFail + " Max High"
+ if max_medium is not None:
+ if sum_new_findings[2] > max_medium:
+ strFail = strFail + " Max Medium"
+ if strFail is None:
+ print "Build Passed!"
+ else:
+ print "Build Failed: " + strFail
+ print"=============================================="
+
+def sum_severity(findings):
+ severity = [0,0,0,0,0]
+ for finding in findings.data["objects"]:
+ if finding["severity"] == "Critical":
+ severity[4] = severity[4] + 1
+ if finding["severity"] == "High":
+ severity[3] = severity[3] + 1
+ if finding["severity"] == "Medium":
+ severity[2] = severity[2] + 1
+ if finding["severity"] == "Low":
+ severity[1] = severity[1] + 1
+ if finding["severity"] == "Info":
+ severity[0] = severity[0] + 1
+
+ return severity
+
+def print_findings(findings):
+ print "Critical: " + str(findings[4])
+ print "High: " + str(findings[3])
+ print "Medium: " + str(findings[2])
+ print "Low: " + str(findings[1])
+ print "Info: " + str(findings[0])
class Main:
if __name__ == "__main__":
@@ -134,8 +238,9 @@ class Main:
parser.add_argument('--api_key', help="API Key", required=True)
parser.add_argument('--user', help="User", required=True)
parser.add_argument('--product', help="Dojo Product ID", required=True)
- parser.add_argument('--file', help="Scanner file", required=True)
- parser.add_argument('--scanner', help="Type of scanner", required=True)
+ parser.add_argument('--file', help="Scanner file", required=False)
+ parser.add_argument('--dir', help="Scanner directory, needs to have the scanner name with the scan file in the folder. Ex: reports/nmap/nmap.csv", required=False)
+ parser.add_argument('--scanner', help="Type of scanner", required=False)
parser.add_argument('--build', help="Build ID", required=False)
parser.add_argument('--engagement', help="Engagement ID (optional)", required=False)
parser.add_argument('--critical', help="Maximum new critical vulns to pass the build.", required=False)
@@ -149,6 +254,7 @@ class Main:
user = args["user"]
product_id = args["product"]
file = args["file"]
+ dir = args["dir"]
scanner = args["scanner"]
engagement_id = args["engagement"]
max_critical = args["critical"]
@@ -156,4 +262,18 @@ class Main:
max_medium = args["medium"]
build = args["build"]
- create_findings(host, api_key, user, product_id, file, scanner, engagement_id, max_critical, max_high, max_medium, build)
+ if dir is not None or file is not None:
+ dd = dojo_connection(host, api_key, user)
+ engagement_id = return_engagement(dd, product_id)
+ test_ids = None
+ if file is not None:
+ if scanner is not None:
+ test_ids = processFiles(dd, engagement_id, file, scanner=scanner)
+ else:
+ print "Scanner type must be specified for a file import. --scanner"
+ else:
+ test_ids = process_findings(dd, engagement_id, dir, build)
+
+ summary(dd, engagement_id, test_ids, max_critical, max_high, max_medium)
+ else:
+ print "No file or directory to scan specified."
diff --git a/examples/reports/.DS_Store b/examples/reports/.DS_Store
new file mode 100644
index 0000000000000000000000000000000000000000..0d3edc4a883fc41d9817b49c6ba491a8d7f757b3
Binary files /dev/null and b/examples/reports/.DS_Store differ
diff --git a/examples/reports/bandit/generic_bandit.csv b/examples/reports/bandit/generic_bandit.csv
new file mode 100644
index 0000000000000000000000000000000000000000..b1fb1707fe258399c308f2c13d64aa3e2c9a81fb
--- /dev/null
+++ b/examples/reports/bandit/generic_bandit.csv
@@ -0,0 +1,2 @@
+Date,Title,CweId,Url,Severity,Description,Mitigation,Impact,References,Active,Verified,FalsePositive,Duplicate
+11/09/2017,blacklist,,,3,"Using cElementTree to parse untrusted XML data is known to be vulnerable to XML attacks. Replace cElementTree with the equivalent defusedxml package, or make sure defusedxml.defuse_stdlib() is called. Filename: PyBitBucket.py Line number: 6 Line range: [6, 7, 8, 9] Issue Confidence: HIGH",,,,False,False,False,False
diff --git a/examples/reports/burp/burp.xml b/examples/reports/burp/burp.xml
new file mode 100644
index 0000000000000000000000000000000000000000..b80bcc67ebb954f56f3b43ee425efdbc807aa4b9
--- /dev/null
+++ b/examples/reports/burp/burp.xml
@@ -0,0 +1,267 @@
+<?xml version="1.0"?>
+<!DOCTYPE issues [
+<!ELEMENT issues (issue*)>
+<!ATTLIST issues burpVersion CDATA "">
+<!ATTLIST issues exportTime CDATA "">
+<!ELEMENT issue (serialNumber, type, name, host, path, location, severity, confidence, issueBackground?, remediationBackground?, references?, vulnerabilityClassifications?, issueDetail?, issueDetailItems?, remediationDetail?, requestresponse*, collaboratorEvent*, infiltratorEvent*)>
+<!ELEMENT serialNumber (#PCDATA)>
+<!ELEMENT type (#PCDATA)>
+<!ELEMENT name (#PCDATA)>
+<!ELEMENT host (#PCDATA)>
+<!ATTLIST host ip CDATA "">
+<!ELEMENT path (#PCDATA)>
+<!ELEMENT location (#PCDATA)>
+<!ELEMENT severity (#PCDATA)>
+<!ELEMENT confidence (#PCDATA)>
+<!ELEMENT issueBackground (#PCDATA)>
+<!ELEMENT remediationBackground (#PCDATA)>
+<!ELEMENT references (#PCDATA)>
+<!ELEMENT vulnerabilityClassifications (#PCDATA)>
+<!ELEMENT issueDetail (#PCDATA)>
+<!ELEMENT issueDetailItems (issueDetailItem*)>
+<!ELEMENT issueDetailItem (#PCDATA)>
+<!ELEMENT remediationDetail (#PCDATA)>
+<!ELEMENT requestresponse (request?, response?, responseRedirected?)>
+<!ELEMENT request (#PCDATA)>
+<!ATTLIST request method CDATA "">
+<!ATTLIST request base64 (true|false) "false">
+<!ELEMENT response (#PCDATA)>
+<!ATTLIST response base64 (true|false) "false">
+<!ELEMENT responseRedirected (#PCDATA)>
+<!ELEMENT sender (#PCDATA)>
+<!ELEMENT message (#PCDATA)>
+<!ELEMENT conversation (#PCDATA)>
+<!ELEMENT recipient (#PCDATA)>
+<!ELEMENT recipients (recipient*)>
+<!ELEMENT smtp (sender, recipients, message, conversation)>
+<!ELEMENT collaboratorEvent (interactionType, originIp, time, lookupType?, lookupHost?, requestresponse?, smtp?)>
+<!ELEMENT interactionType (#PCDATA)>
+<!ELEMENT originIp (#PCDATA)>
+<!ELEMENT time (#PCDATA)>
+<!ELEMENT lookupType (#PCDATA)>
+<!ELEMENT lookupHost (#PCDATA)>
+<!ELEMENT infiltratorEvent (parameterName, platform, signature, stackTrace?, parameterValue?, collaboratorEvent)>
+<!ELEMENT parameterName (#PCDATA)>
+<!ELEMENT platform (#PCDATA)>
+<!ELEMENT signature (#PCDATA)>
+<!ELEMENT stackTrace (#PCDATA)>
+<!ELEMENT parameterValue (#PCDATA)>
+]>
+<issues burpVersion="1.7.27" exportTime="Fri Nov 10 10:46:16 EST 2017">
+ <issue>
+ <serialNumber>4332586205316654080</serialNumber>
+ <type>1049088</type>
+ <name><![CDATA[SQL injection]]></name>
+ <host ip="198.252.230.171">https://kace.nabancard.com</host>
+ <path><![CDATA[/common/user_profile.php]]></path>
+ <location><![CDATA[/common/user_profile.php [sort_column parameter]]]></location>
+ <severity>High</severity>
+ <confidence>Firm</confidence>
+ <issueBackground><![CDATA[<p>SQL injection vulnerabilities arise when user-controllable data is incorporated into database SQL queries in an unsafe manner. An attacker can supply crafted input to break out of the data context in which their input appears and interfere with the structure of the surrounding query.</p>
+<p>A wide range of damaging attacks can often be delivered via SQL injection, including reading or modifying critical application data, interfering with application logic, escalating privileges within the database and taking control of the database server. </p>]]></issueBackground>
+ <remediationBackground><![CDATA[<p>The most effective way to prevent SQL injection attacks is to use parameterized queries (also known as prepared statements) for all database access. This method uses two steps to incorporate potentially tainted data into SQL queries: first, the application specifies the structure of the query, leaving placeholders for each item of user input; second, the application specifies the contents of each placeholder. Because the structure of the query has already been defined in the first step, it is not possible for malformed data in the second step to interfere with the query structure. You should review the documentation for your database and application platform to determine the appropriate APIs which you can use to perform parameterized queries. It is strongly recommended that you parameterize <i>every</i> variable data item that is incorporated into database queries, even if it is not obviously tainted, to prevent oversights occurring and avoid vulnerabilities being introduced by changes elsewhere within the code base of the application.</p>
+<p>You should be aware that some commonly employed and recommended mitigations for SQL injection vulnerabilities are not always effective: </p>
+<ul>
+ <li>One common defense is to double up any single quotation marks appearing within user input before incorporating that input into a SQL query. This defense is designed to prevent malformed data from terminating the string into which it is inserted. However, if the data being incorporated into queries is numeric, then the defense may fail, because numeric data may not be encapsulated within quotes, in which case only a space is required to break out of the data context and interfere with the query. Further, in second-order SQL injection attacks, data that has been safely escaped when initially inserted into the database is subsequently read from the database and then passed back to it again. Quotation marks that have been doubled up initially will return to their original form when the data is reused, allowing the defense to be bypassed.</li>
+ <li>Another often cited defense is to use stored procedures for database access. While stored procedures can provide security benefits, they are not guaranteed to prevent SQL injection attacks. The same kinds of vulnerabilities that arise within standard dynamic SQL queries can arise if any SQL is dynamically constructed within stored procedures. Further, even if the procedure is sound, SQL injection can arise if the procedure is invoked in an unsafe manner using user-controllable data.</li>
+</ul>]]></remediationBackground>
+ <references><![CDATA[<ul>
+<li><a href="https://support.portswigger.net/customer/portal/articles/1965677-using-burp-to-test-for-injection-flaws">Using Burp to Test for Injection Flaws</a></li>
+<li><a href="http://websec.ca/kb/sql_injection">SQL Injection Cheat Sheet</a></li>
+<li><a href="https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet">SQL Injection Prevention Cheat Sheet</a></li>
+</ul>]]></references>
+ <vulnerabilityClassifications><![CDATA[<ul>
+<li><a href="https://cwe.mitre.org/data/definitions/89.html">CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')</a></li>
+<li><a href="https://cwe.mitre.org/data/definitions/94.html">CWE-94: Improper Control of Generation of Code ('Code Injection')
+</a></li>
+<li><a href="https://cwe.mitre.org/data/definitions/116.html">CWE-116: Improper Encoding or Escaping of Output</a></li>
+</ul>]]></vulnerabilityClassifications>
+ <issueDetail><![CDATA[The <b>sort_column</b> parameter appears to be vulnerable to SQL injection attacks. The payload <b>,(select*from(select(sleep(20)))a)</b> was submitted in the sort_column parameter. The application took <b>20562</b> milliseconds to respond to the request, compared with <b>1980</b> milliseconds for the original request, indicating that the injected SQL command caused a time delay.<br><br>The database appears to be MySQL.]]></issueDetail>
+ <requestresponse>
+ <request method="GET" base64="true"><![CDATA[R0VUIC9jb21tb24vdXNlcl9wcm9maWxlLnBocD9JRD01NDkmdGFibGVfaWQ9dXBfYXNzaWduZWRfZGV2aWNlc190YWJsZSZzb3J0X2NvbHVtbj1JU19QUklNQVJZX0RFVklDRSUyYyhzZWxlY3QqZnJvbShzZWxlY3Qoc2xlZXAoMjApKSlhKSZzb3J0X2RpcmVjdGlvbj1kZXNjJnJlY29yZHNfcGVyX3BhZ2U9NSZwYWdlX251bWJlcj0xIEhUVFAvMS4xDQpIb3N0OiBrYWNlLm5hYmFuY2FyZC5jb20NClVzZXItQWdlbnQ6IE1vemlsbGEvNS4wIChNYWNpbnRvc2g7IEludGVsIE1hYyBPUyBYIDEwLjEyOyBydjo1Ni4wKSBHZWNrby8yMDEwMDEwMSBGaXJlZm94LzU2LjANCkFjY2VwdDogYXBwbGljYXRpb24vanNvbiwgdGV4dC9qYXZhc2NyaXB0LCAqLyo7IHE9MC4wMQ0KQWNjZXB0LUxhbmd1YWdlOiBlbi1VUyxlbjtxPTAuNQ0KQWNjZXB0LUVuY29kaW5nOiBnemlwLCBkZWZsYXRlDQpSZWZlcmVyOiBodHRwczovL2thY2UubmFiYW5jYXJkLmNvbS91c2VydWkvYWR2aXNvcnlfZGV0YWlsLnBocD9JRD0xJTIwKyUyMDENClgtUmVxdWVzdGVkLVdpdGg6IFhNTEh0dHBSZXF1ZXN0DQpDb29raWU6IGtib3hpZD1lbWkzbmZtaDUyMW82OWE1dGQ5bHY3M2ViNjsgS0FDRV9DU1JGX1RPS0VOPTMyZWIxOTg3MmU3NTYwYWExNjMyYzQ5ODc2OTEwYzUwYjdiOTMwMDY5YWRkOGYwNDIzYjBlNzVjYjY3YjRiYjdkM2U3MDMyMWRiY2U0MDRhYjEzZTU0NjkwNmY2ZWM5ODAwY2RjYzRjMTZmZWEwYWNiMjBhN2FmNTdjNDRkNzkzOyBLQUNFX0xBU1RfVVNFUl9TRUNVUkU9JTlDJTlFJTA3JTkwJUEwJUM5JUUzJUVDJTBCJTFEJUIwJTgyJUIzJThGJTg2cDsgS0FDRV9MQVNUX09SR19TRUNVUkU9JURFJUEzJTBFMjAlOEUlODQlQkYlQjElRDUlODklRTAlQTglRTYlMkElRkQ7IHgtZGVsbC1hdXRoLWp3dD1leUowZVhBaU9pSktWMVFpTENKaGJHY2lPaUpTVXpJMU5pSjkuZXlKcGMzTWlPaUpCVFZOSlpHVnVkR2wwZVZCeWIzWnBaR1Z5SWl3aWMzVmlJam8xTkRFc0ltRjFaQ0k2SWtWVFRWQnNZWFJtYjNKdElpd2lZMjl1SWpvaVkyVTBaak5qT0RZeE5EWTBORGxqTVRnM056YzBPV1l3TXpjNE5qVmlPRFVpTENKbGVIQWlPakUxTVRBeE9EUTROalY5LlNCcl9rSUwwdVJYQ0RVYV9WdzVGM2NMRVRXalJ6NlI1VlZYSlpPYUpjT2FqYUJla2Q4RW5xM3FSU0FhdXY1TmVQR0NQOWRra3JHQ0JUWjZqeHlMZ19HOEM1MV9iekl0ckM2OS1meFZZLXlqaGNPX1dlSi1MREpITGRPbVhaWm1oQ1NWSmhyTHJ1blNJc0xESmJ3cHFGV0ZhRGJtN05KWWM5NXMxcGU3a1FnMDsgS0FDRV9MQVNUX0FETUlOX1NFQ1VSRT0lOUMlOUUlMDclOTAlQTAlQzklRTMlRUMlMEIlMUQlQjAlODIlQjMlOEYlODZwDQpDb25uZWN0aW9uOiBjbG9zZQ0KDQo=]]></request>
+ <response base64="true"><![CDATA[SFRUUC8xLjEgMjAwIE9LDQpEYXRlOiBXZWQsIDA4IE5vdiAyMDE3IDE5OjUwOjE0IEdNVA0KU2VydmVyOiBBcGFjaGUNCkV4cGlyZXM6IFRodSwgMTkgTm92IDE5ODEgMDg6NTI6MDAgR01UDQpDYWNoZS1Db250cm9sOiBuby1zdG9yZSwgbm8tY2FjaGUsIG11c3QtcmV2YWxpZGF0ZSwgcG9zdC1jaGVjaz0wLCBwcmUtY2hlY2s9MA0KUHJhZ21hOiBuby1jYWNoZQ0KVmFyeTogQWNjZXB0LUVuY29kaW5nDQpBY2Nlc3MtQ29udHJvbC1BbGxvdy1IZWFkZXJzOiB4LWRlbGwtYXV0aC10aW1lc3RhbXAsIHgtZGVsbC1hdXRoLWtleSwgeC1kZWxsLWF1dGgtc2lnbmF0dXJlLCBhY2NlcHQsIG9yaWdpbiwgY29udGVudC10eXBlDQpBY2Nlc3MtQ29udHJvbC1BbGxvdy1PcmlnaW46ICoNCkFjY2Vzcy1Db250cm9sLUFsbG93LU1ldGhvZHM6IFBVVCwgREVMRVRFLCBQT1NULCBHRVQsIE9QVElPTlMNClgtRGVsbEtBQ0UtQXBwbGlhbmNlOiBrMTAwMA0KWC1EZWxsS0FDRS1Ib3N0OiBLQUNFLm5hYmFuY2FyZC5jb20NClgtRGVsbEtBQ0UtVmVyc2lvbjogNy4yLjEwMg0KWC1LQk9YLVdlYlNlcnZlcjogS0FDRS5uYWJhbmNhcmQuY29tDQpYLUtCT1gtVmVyc2lvbjogNy4yLjEwMg0KWC1LQUNFLUFwcGxpYW5jZTogSzEwMDANClgtS0FDRS1Ib3N0OiBLQUNFLm5hYmFuY2FyZC5jb20NClgtS0FDRS1WZXJzaW9uOiA3LjIuMTAyDQpYLUtBQ0UtV2ViU2VydmVyOiBLQUNFLm5hYmFuY2FyZC5jb20NClgtVUEtQ29tcGF0aWJsZTogSUU9OSxFREdFDQpDYWNoZS1Db250cm9sOiBwcml2YXRlLCBuby1jYWNoZSwgbm8tc3RvcmUsIHByb3h5LXJldmFsaWRhdGUsIG5vLXRyYW5zZm9ybQ0KQ29udGVudC1MZW5ndGg6IDQ0DQpDb25uZWN0aW9uOiBjbG9zZQ0KQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgNClN0cmljdC1UcmFuc3BvcnQtU2VjdXJpdHk6IG1heC1hZ2U9MTU3NjgwMDANCg0KeyJjdXJyZW50X3BhZ2UiOjEsInRvdGFsX3BhZ2VzIjowLCJyb3dzIjpbXX0=]]></response>
+ <responseRedirected>false</responseRedirected>
+ </requestresponse>
+ </issue>
+ <issue>
+ <serialNumber>268361935394890752</serialNumber>
+ <type>1049088</type>
+ <name><![CDATA[SQL injection]]></name>
+ <host ip="198.252.230.171">https://kace.nabancard.com</host>
+ <path><![CDATA[/common/user_profile.php]]></path>
+ <location><![CDATA[/common/user_profile.php [sort_direction parameter]]]></location>
+ <severity>High</severity>
+ <confidence>Firm</confidence>
+ <issueBackground><![CDATA[<p>SQL injection vulnerabilities arise when user-controllable data is incorporated into database SQL queries in an unsafe manner. An attacker can supply crafted input to break out of the data context in which their input appears and interfere with the structure of the surrounding query.</p>
+<p>A wide range of damaging attacks can often be delivered via SQL injection, including reading or modifying critical application data, interfering with application logic, escalating privileges within the database and taking control of the database server. </p>]]></issueBackground>
+ <remediationBackground><![CDATA[<p>The most effective way to prevent SQL injection attacks is to use parameterized queries (also known as prepared statements) for all database access. This method uses two steps to incorporate potentially tainted data into SQL queries: first, the application specifies the structure of the query, leaving placeholders for each item of user input; second, the application specifies the contents of each placeholder. Because the structure of the query has already been defined in the first step, it is not possible for malformed data in the second step to interfere with the query structure. You should review the documentation for your database and application platform to determine the appropriate APIs which you can use to perform parameterized queries. It is strongly recommended that you parameterize <i>every</i> variable data item that is incorporated into database queries, even if it is not obviously tainted, to prevent oversights occurring and avoid vulnerabilities being introduced by changes elsewhere within the code base of the application.</p>
+<p>You should be aware that some commonly employed and recommended mitigations for SQL injection vulnerabilities are not always effective: </p>
+<ul>
+ <li>One common defense is to double up any single quotation marks appearing within user input before incorporating that input into a SQL query. This defense is designed to prevent malformed data from terminating the string into which it is inserted. However, if the data being incorporated into queries is numeric, then the defense may fail, because numeric data may not be encapsulated within quotes, in which case only a space is required to break out of the data context and interfere with the query. Further, in second-order SQL injection attacks, data that has been safely escaped when initially inserted into the database is subsequently read from the database and then passed back to it again. Quotation marks that have been doubled up initially will return to their original form when the data is reused, allowing the defense to be bypassed.</li>
+ <li>Another often cited defense is to use stored procedures for database access. While stored procedures can provide security benefits, they are not guaranteed to prevent SQL injection attacks. The same kinds of vulnerabilities that arise within standard dynamic SQL queries can arise if any SQL is dynamically constructed within stored procedures. Further, even if the procedure is sound, SQL injection can arise if the procedure is invoked in an unsafe manner using user-controllable data.</li>
+</ul>]]></remediationBackground>
+ <references><![CDATA[<ul>
+<li><a href="https://support.portswigger.net/customer/portal/articles/1965677-using-burp-to-test-for-injection-flaws">Using Burp to Test for Injection Flaws</a></li>
+<li><a href="http://websec.ca/kb/sql_injection">SQL Injection Cheat Sheet</a></li>
+<li><a href="https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet">SQL Injection Prevention Cheat Sheet</a></li>
+</ul>]]></references>
+ <vulnerabilityClassifications><![CDATA[<ul>
+<li><a href="https://cwe.mitre.org/data/definitions/89.html">CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')</a></li>
+<li><a href="https://cwe.mitre.org/data/definitions/94.html">CWE-94: Improper Control of Generation of Code ('Code Injection')
+</a></li>
+<li><a href="https://cwe.mitre.org/data/definitions/116.html">CWE-116: Improper Encoding or Escaping of Output</a></li>
+</ul>]]></vulnerabilityClassifications>
+ <issueDetail><![CDATA[The <b>sort_direction</b> parameter appears to be vulnerable to SQL injection attacks. The payload <b>,(select*from(select(sleep(20)))a)</b> was submitted in the sort_direction parameter. The application took <b>20314</b> milliseconds to respond to the request, compared with <b>1980</b> milliseconds for the original request, indicating that the injected SQL command caused a time delay.<br><br>The database appears to be MySQL.]]></issueDetail>
+ <requestresponse>
+ <request method="GET" base64="true"><![CDATA[R0VUIC9jb21tb24vdXNlcl9wcm9maWxlLnBocD9JRD01NDkmdGFibGVfaWQ9dXBfYXNzaWduZWRfZGV2aWNlc190YWJsZSZzb3J0X2NvbHVtbj1JU19QUklNQVJZX0RFVklDRSZzb3J0X2RpcmVjdGlvbj1kZXNjJTJjKHNlbGVjdCpmcm9tKHNlbGVjdChzbGVlcCgyMCkpKWEpJnJlY29yZHNfcGVyX3BhZ2U9NSZwYWdlX251bWJlcj0xIEhUVFAvMS4xDQpIb3N0OiBrYWNlLm5hYmFuY2FyZC5jb20NClVzZXItQWdlbnQ6IE1vemlsbGEvNS4wIChNYWNpbnRvc2g7IEludGVsIE1hYyBPUyBYIDEwLjEyOyBydjo1Ni4wKSBHZWNrby8yMDEwMDEwMSBGaXJlZm94LzU2LjANCkFjY2VwdDogYXBwbGljYXRpb24vanNvbiwgdGV4dC9qYXZhc2NyaXB0LCAqLyo7IHE9MC4wMQ0KQWNjZXB0LUxhbmd1YWdlOiBlbi1VUyxlbjtxPTAuNQ0KQWNjZXB0LUVuY29kaW5nOiBnemlwLCBkZWZsYXRlDQpSZWZlcmVyOiBodHRwczovL2thY2UubmFiYW5jYXJkLmNvbS91c2VydWkvYWR2aXNvcnlfZGV0YWlsLnBocD9JRD0xJTIwKyUyMDENClgtUmVxdWVzdGVkLVdpdGg6IFhNTEh0dHBSZXF1ZXN0DQpDb29raWU6IGtib3hpZD1lbWkzbmZtaDUyMW82OWE1dGQ5bHY3M2ViNjsgS0FDRV9DU1JGX1RPS0VOPTMyZWIxOTg3MmU3NTYwYWExNjMyYzQ5ODc2OTEwYzUwYjdiOTMwMDY5YWRkOGYwNDIzYjBlNzVjYjY3YjRiYjdkM2U3MDMyMWRiY2U0MDRhYjEzZTU0NjkwNmY2ZWM5ODAwY2RjYzRjMTZmZWEwYWNiMjBhN2FmNTdjNDRkNzkzOyBLQUNFX0xBU1RfVVNFUl9TRUNVUkU9JTlDJTlFJTA3JTkwJUEwJUM5JUUzJUVDJTBCJTFEJUIwJTgyJUIzJThGJTg2cDsgS0FDRV9MQVNUX09SR19TRUNVUkU9JURFJUEzJTBFMjAlOEUlODQlQkYlQjElRDUlODklRTAlQTglRTYlMkElRkQ7IHgtZGVsbC1hdXRoLWp3dD1leUowZVhBaU9pSktWMVFpTENKaGJHY2lPaUpTVXpJMU5pSjkuZXlKcGMzTWlPaUpCVFZOSlpHVnVkR2wwZVZCeWIzWnBaR1Z5SWl3aWMzVmlJam8xTkRFc0ltRjFaQ0k2SWtWVFRWQnNZWFJtYjNKdElpd2lZMjl1SWpvaVkyVTBaak5qT0RZeE5EWTBORGxqTVRnM056YzBPV1l3TXpjNE5qVmlPRFVpTENKbGVIQWlPakUxTVRBeE9EUTROalY5LlNCcl9rSUwwdVJYQ0RVYV9WdzVGM2NMRVRXalJ6NlI1VlZYSlpPYUpjT2FqYUJla2Q4RW5xM3FSU0FhdXY1TmVQR0NQOWRra3JHQ0JUWjZqeHlMZ19HOEM1MV9iekl0ckM2OS1meFZZLXlqaGNPX1dlSi1MREpITGRPbVhaWm1oQ1NWSmhyTHJ1blNJc0xESmJ3cHFGV0ZhRGJtN05KWWM5NXMxcGU3a1FnMDsgS0FDRV9MQVNUX0FETUlOX1NFQ1VSRT0lOUMlOUUlMDclOTAlQTAlQzklRTMlRUMlMEIlMUQlQjAlODIlQjMlOEYlODZwDQpDb25uZWN0aW9uOiBjbG9zZQ0KDQo=]]></request>
+ <response base64="true"><![CDATA[SFRUUC8xLjEgMjAwIE9LDQpEYXRlOiBXZWQsIDA4IE5vdiAyMDE3IDE5OjUyOjI2IEdNVA0KU2VydmVyOiBBcGFjaGUNCkV4cGlyZXM6IFRodSwgMTkgTm92IDE5ODEgMDg6NTI6MDAgR01UDQpDYWNoZS1Db250cm9sOiBuby1zdG9yZSwgbm8tY2FjaGUsIG11c3QtcmV2YWxpZGF0ZSwgcG9zdC1jaGVjaz0wLCBwcmUtY2hlY2s9MA0KUHJhZ21hOiBuby1jYWNoZQ0KVmFyeTogQWNjZXB0LUVuY29kaW5nDQpBY2Nlc3MtQ29udHJvbC1BbGxvdy1IZWFkZXJzOiB4LWRlbGwtYXV0aC10aW1lc3RhbXAsIHgtZGVsbC1hdXRoLWtleSwgeC1kZWxsLWF1dGgtc2lnbmF0dXJlLCBhY2NlcHQsIG9yaWdpbiwgY29udGVudC10eXBlDQpBY2Nlc3MtQ29udHJvbC1BbGxvdy1PcmlnaW46ICoNCkFjY2Vzcy1Db250cm9sLUFsbG93LU1ldGhvZHM6IFBVVCwgREVMRVRFLCBQT1NULCBHRVQsIE9QVElPTlMNClgtRGVsbEtBQ0UtQXBwbGlhbmNlOiBrMTAwMA0KWC1EZWxsS0FDRS1Ib3N0OiBLQUNFLm5hYmFuY2FyZC5jb20NClgtRGVsbEtBQ0UtVmVyc2lvbjogNy4yLjEwMg0KWC1LQk9YLVdlYlNlcnZlcjogS0FDRS5uYWJhbmNhcmQuY29tDQpYLUtCT1gtVmVyc2lvbjogNy4yLjEwMg0KWC1LQUNFLUFwcGxpYW5jZTogSzEwMDANClgtS0FDRS1Ib3N0OiBLQUNFLm5hYmFuY2FyZC5jb20NClgtS0FDRS1WZXJzaW9uOiA3LjIuMTAyDQpYLUtBQ0UtV2ViU2VydmVyOiBLQUNFLm5hYmFuY2FyZC5jb20NClgtVUEtQ29tcGF0aWJsZTogSUU9OSxFREdFDQpDYWNoZS1Db250cm9sOiBwcml2YXRlLCBuby1jYWNoZSwgbm8tc3RvcmUsIHByb3h5LXJldmFsaWRhdGUsIG5vLXRyYW5zZm9ybQ0KQ29udGVudC1MZW5ndGg6IDQ0DQpDb25uZWN0aW9uOiBjbG9zZQ0KQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgNClN0cmljdC1UcmFuc3BvcnQtU2VjdXJpdHk6IG1heC1hZ2U9MTU3NjgwMDANCg0KeyJjdXJyZW50X3BhZ2UiOjEsInRvdGFsX3BhZ2VzIjowLCJyb3dzIjpbXX0=]]></response>
+ <responseRedirected>false</responseRedirected>
+ </requestresponse>
+ </issue>
+ <issue>
+ <serialNumber>4332586205316654080</serialNumber>
+ <type>1049088</type>
+ <name><![CDATA[SQL injection]]></name>
+ <host ip="198.252.230.171">https://kace.nabancard.com</host>
+ <path><![CDATA[/common/user_profile.php]]></path>
+ <location><![CDATA[/common/user_profile.php [sort_column parameter]]]></location>
+ <severity>High</severity>
+ <confidence>Firm</confidence>
+ <issueBackground><![CDATA[<p>SQL injection vulnerabilities arise when user-controllable data is incorporated into database SQL queries in an unsafe manner. An attacker can supply crafted input to break out of the data context in which their input appears and interfere with the structure of the surrounding query.</p>
+<p>A wide range of damaging attacks can often be delivered via SQL injection, including reading or modifying critical application data, interfering with application logic, escalating privileges within the database and taking control of the database server. </p>]]></issueBackground>
+ <remediationBackground><![CDATA[<p>The most effective way to prevent SQL injection attacks is to use parameterized queries (also known as prepared statements) for all database access. This method uses two steps to incorporate potentially tainted data into SQL queries: first, the application specifies the structure of the query, leaving placeholders for each item of user input; second, the application specifies the contents of each placeholder. Because the structure of the query has already been defined in the first step, it is not possible for malformed data in the second step to interfere with the query structure. You should review the documentation for your database and application platform to determine the appropriate APIs which you can use to perform parameterized queries. It is strongly recommended that you parameterize <i>every</i> variable data item that is incorporated into database queries, even if it is not obviously tainted, to prevent oversights occurring and avoid vulnerabilities being introduced by changes elsewhere within the code base of the application.</p>
+<p>You should be aware that some commonly employed and recommended mitigations for SQL injection vulnerabilities are not always effective: </p>
+<ul>
+ <li>One common defense is to double up any single quotation marks appearing within user input before incorporating that input into a SQL query. This defense is designed to prevent malformed data from terminating the string into which it is inserted. However, if the data being incorporated into queries is numeric, then the defense may fail, because numeric data may not be encapsulated within quotes, in which case only a space is required to break out of the data context and interfere with the query. Further, in second-order SQL injection attacks, data that has been safely escaped when initially inserted into the database is subsequently read from the database and then passed back to it again. Quotation marks that have been doubled up initially will return to their original form when the data is reused, allowing the defense to be bypassed.</li>
+ <li>Another often cited defense is to use stored procedures for database access. While stored procedures can provide security benefits, they are not guaranteed to prevent SQL injection attacks. The same kinds of vulnerabilities that arise within standard dynamic SQL queries can arise if any SQL is dynamically constructed within stored procedures. Further, even if the procedure is sound, SQL injection can arise if the procedure is invoked in an unsafe manner using user-controllable data.</li>
+</ul>]]></remediationBackground>
+ <references><![CDATA[<ul>
+<li><a href="https://support.portswigger.net/customer/portal/articles/1965677-using-burp-to-test-for-injection-flaws">Using Burp to Test for Injection Flaws</a></li>
+<li><a href="http://websec.ca/kb/sql_injection">SQL Injection Cheat Sheet</a></li>
+<li><a href="https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet">SQL Injection Prevention Cheat Sheet</a></li>
+</ul>]]></references>
+ <vulnerabilityClassifications><![CDATA[<ul>
+<li><a href="https://cwe.mitre.org/data/definitions/89.html">CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')</a></li>
+<li><a href="https://cwe.mitre.org/data/definitions/94.html">CWE-94: Improper Control of Generation of Code ('Code Injection')
+</a></li>
+<li><a href="https://cwe.mitre.org/data/definitions/116.html">CWE-116: Improper Encoding or Escaping of Output</a></li>
+</ul>]]></vulnerabilityClassifications>
+ <issueDetail><![CDATA[The <b>sort_column</b> parameter appears to be vulnerable to SQL injection attacks. The payload <b>,(select*from(select(sleep(20)))a)</b> was submitted in the sort_column parameter. The application took <b>20562</b> milliseconds to respond to the request, compared with <b>1980</b> milliseconds for the original request, indicating that the injected SQL command caused a time delay.<br><br>The database appears to be MySQL.]]></issueDetail>
+ <requestresponse>
+ <request method="GET" base64="true"><![CDATA[R0VUIC9jb21tb24vdXNlcl9wcm9maWxlLnBocD9JRD01NDkmdGFibGVfaWQ9dXBfYXNzaWduZWRfZGV2aWNlc190YWJsZSZzb3J0X2NvbHVtbj1JU19QUklNQVJZX0RFVklDRSUyYyhzZWxlY3QqZnJvbShzZWxlY3Qoc2xlZXAoMjApKSlhKSZzb3J0X2RpcmVjdGlvbj1kZXNjJnJlY29yZHNfcGVyX3BhZ2U9NSZwYWdlX251bWJlcj0xIEhUVFAvMS4xDQpIb3N0OiBrYWNlLm5hYmFuY2FyZC5jb20NClVzZXItQWdlbnQ6IE1vemlsbGEvNS4wIChNYWNpbnRvc2g7IEludGVsIE1hYyBPUyBYIDEwLjEyOyBydjo1Ni4wKSBHZWNrby8yMDEwMDEwMSBGaXJlZm94LzU2LjANCkFjY2VwdDogYXBwbGljYXRpb24vanNvbiwgdGV4dC9qYXZhc2NyaXB0LCAqLyo7IHE9MC4wMQ0KQWNjZXB0LUxhbmd1YWdlOiBlbi1VUyxlbjtxPTAuNQ0KQWNjZXB0LUVuY29kaW5nOiBnemlwLCBkZWZsYXRlDQpSZWZlcmVyOiBodHRwczovL2thY2UubmFiYW5jYXJkLmNvbS91c2VydWkvYWR2aXNvcnlfZGV0YWlsLnBocD9JRD0xJTIwKyUyMDENClgtUmVxdWVzdGVkLVdpdGg6IFhNTEh0dHBSZXF1ZXN0DQpDb29raWU6IGtib3hpZD1lbWkzbmZtaDUyMW82OWE1dGQ5bHY3M2ViNjsgS0FDRV9DU1JGX1RPS0VOPTMyZWIxOTg3MmU3NTYwYWExNjMyYzQ5ODc2OTEwYzUwYjdiOTMwMDY5YWRkOGYwNDIzYjBlNzVjYjY3YjRiYjdkM2U3MDMyMWRiY2U0MDRhYjEzZTU0NjkwNmY2ZWM5ODAwY2RjYzRjMTZmZWEwYWNiMjBhN2FmNTdjNDRkNzkzOyBLQUNFX0xBU1RfVVNFUl9TRUNVUkU9JTlDJTlFJTA3JTkwJUEwJUM5JUUzJUVDJTBCJTFEJUIwJTgyJUIzJThGJTg2cDsgS0FDRV9MQVNUX09SR19TRUNVUkU9JURFJUEzJTBFMjAlOEUlODQlQkYlQjElRDUlODklRTAlQTglRTYlMkElRkQ7IHgtZGVsbC1hdXRoLWp3dD1leUowZVhBaU9pSktWMVFpTENKaGJHY2lPaUpTVXpJMU5pSjkuZXlKcGMzTWlPaUpCVFZOSlpHVnVkR2wwZVZCeWIzWnBaR1Z5SWl3aWMzVmlJam8xTkRFc0ltRjFaQ0k2SWtWVFRWQnNZWFJtYjNKdElpd2lZMjl1SWpvaVkyVTBaak5qT0RZeE5EWTBORGxqTVRnM056YzBPV1l3TXpjNE5qVmlPRFVpTENKbGVIQWlPakUxTVRBeE9EUTROalY5LlNCcl9rSUwwdVJYQ0RVYV9WdzVGM2NMRVRXalJ6NlI1VlZYSlpPYUpjT2FqYUJla2Q4RW5xM3FSU0FhdXY1TmVQR0NQOWRra3JHQ0JUWjZqeHlMZ19HOEM1MV9iekl0ckM2OS1meFZZLXlqaGNPX1dlSi1MREpITGRPbVhaWm1oQ1NWSmhyTHJ1blNJc0xESmJ3cHFGV0ZhRGJtN05KWWM5NXMxcGU3a1FnMDsgS0FDRV9MQVNUX0FETUlOX1NFQ1VSRT0lOUMlOUUlMDclOTAlQTAlQzklRTMlRUMlMEIlMUQlQjAlODIlQjMlOEYlODZwDQpDb25uZWN0aW9uOiBjbG9zZQ0KDQo=]]></request>
+ <response base64="true"><![CDATA[SFRUUC8xLjEgMjAwIE9LDQpEYXRlOiBXZWQsIDA4IE5vdiAyMDE3IDE5OjUwOjE0IEdNVA0KU2VydmVyOiBBcGFjaGUNCkV4cGlyZXM6IFRodSwgMTkgTm92IDE5ODEgMDg6NTI6MDAgR01UDQpDYWNoZS1Db250cm9sOiBuby1zdG9yZSwgbm8tY2FjaGUsIG11c3QtcmV2YWxpZGF0ZSwgcG9zdC1jaGVjaz0wLCBwcmUtY2hlY2s9MA0KUHJhZ21hOiBuby1jYWNoZQ0KVmFyeTogQWNjZXB0LUVuY29kaW5nDQpBY2Nlc3MtQ29udHJvbC1BbGxvdy1IZWFkZXJzOiB4LWRlbGwtYXV0aC10aW1lc3RhbXAsIHgtZGVsbC1hdXRoLWtleSwgeC1kZWxsLWF1dGgtc2lnbmF0dXJlLCBhY2NlcHQsIG9yaWdpbiwgY29udGVudC10eXBlDQpBY2Nlc3MtQ29udHJvbC1BbGxvdy1PcmlnaW46ICoNCkFjY2Vzcy1Db250cm9sLUFsbG93LU1ldGhvZHM6IFBVVCwgREVMRVRFLCBQT1NULCBHRVQsIE9QVElPTlMNClgtRGVsbEtBQ0UtQXBwbGlhbmNlOiBrMTAwMA0KWC1EZWxsS0FDRS1Ib3N0OiBLQUNFLm5hYmFuY2FyZC5jb20NClgtRGVsbEtBQ0UtVmVyc2lvbjogNy4yLjEwMg0KWC1LQk9YLVdlYlNlcnZlcjogS0FDRS5uYWJhbmNhcmQuY29tDQpYLUtCT1gtVmVyc2lvbjogNy4yLjEwMg0KWC1LQUNFLUFwcGxpYW5jZTogSzEwMDANClgtS0FDRS1Ib3N0OiBLQUNFLm5hYmFuY2FyZC5jb20NClgtS0FDRS1WZXJzaW9uOiA3LjIuMTAyDQpYLUtBQ0UtV2ViU2VydmVyOiBLQUNFLm5hYmFuY2FyZC5jb20NClgtVUEtQ29tcGF0aWJsZTogSUU9OSxFREdFDQpDYWNoZS1Db250cm9sOiBwcml2YXRlLCBuby1jYWNoZSwgbm8tc3RvcmUsIHByb3h5LXJldmFsaWRhdGUsIG5vLXRyYW5zZm9ybQ0KQ29udGVudC1MZW5ndGg6IDQ0DQpDb25uZWN0aW9uOiBjbG9zZQ0KQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgNClN0cmljdC1UcmFuc3BvcnQtU2VjdXJpdHk6IG1heC1hZ2U9MTU3NjgwMDANCg0KeyJjdXJyZW50X3BhZ2UiOjEsInRvdGFsX3BhZ2VzIjowLCJyb3dzIjpbXX0=]]></response>
+ <responseRedirected>false</responseRedirected>
+ </requestresponse>
+ </issue>
+ <issue>
+ <serialNumber>268361935394890752</serialNumber>
+ <type>1049088</type>
+ <name><![CDATA[SQL injection]]></name>
+ <host ip="198.252.230.171">https://kace.nabancard.com</host>
+ <path><![CDATA[/common/user_profile.php]]></path>
+ <location><![CDATA[/common/user_profile.php [sort_direction parameter]]]></location>
+ <severity>High</severity>
+ <confidence>Firm</confidence>
+ <issueBackground><![CDATA[<p>SQL injection vulnerabilities arise when user-controllable data is incorporated into database SQL queries in an unsafe manner. An attacker can supply crafted input to break out of the data context in which their input appears and interfere with the structure of the surrounding query.</p>
+<p>A wide range of damaging attacks can often be delivered via SQL injection, including reading or modifying critical application data, interfering with application logic, escalating privileges within the database and taking control of the database server. </p>]]></issueBackground>
+ <remediationBackground><![CDATA[<p>The most effective way to prevent SQL injection attacks is to use parameterized queries (also known as prepared statements) for all database access. This method uses two steps to incorporate potentially tainted data into SQL queries: first, the application specifies the structure of the query, leaving placeholders for each item of user input; second, the application specifies the contents of each placeholder. Because the structure of the query has already been defined in the first step, it is not possible for malformed data in the second step to interfere with the query structure. You should review the documentation for your database and application platform to determine the appropriate APIs which you can use to perform parameterized queries. It is strongly recommended that you parameterize <i>every</i> variable data item that is incorporated into database queries, even if it is not obviously tainted, to prevent oversights occurring and avoid vulnerabilities being introduced by changes elsewhere within the code base of the application.</p>
+<p>You should be aware that some commonly employed and recommended mitigations for SQL injection vulnerabilities are not always effective: </p>
+<ul>
+ <li>One common defense is to double up any single quotation marks appearing within user input before incorporating that input into a SQL query. This defense is designed to prevent malformed data from terminating the string into which it is inserted. However, if the data being incorporated into queries is numeric, then the defense may fail, because numeric data may not be encapsulated within quotes, in which case only a space is required to break out of the data context and interfere with the query. Further, in second-order SQL injection attacks, data that has been safely escaped when initially inserted into the database is subsequently read from the database and then passed back to it again. Quotation marks that have been doubled up initially will return to their original form when the data is reused, allowing the defense to be bypassed.</li>
+ <li>Another often cited defense is to use stored procedures for database access. While stored procedures can provide security benefits, they are not guaranteed to prevent SQL injection attacks. The same kinds of vulnerabilities that arise within standard dynamic SQL queries can arise if any SQL is dynamically constructed within stored procedures. Further, even if the procedure is sound, SQL injection can arise if the procedure is invoked in an unsafe manner using user-controllable data.</li>
+</ul>]]></remediationBackground>
+ <references><![CDATA[<ul>
+<li><a href="https://support.portswigger.net/customer/portal/articles/1965677-using-burp-to-test-for-injection-flaws">Using Burp to Test for Injection Flaws</a></li>
+<li><a href="http://websec.ca/kb/sql_injection">SQL Injection Cheat Sheet</a></li>
+<li><a href="https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet">SQL Injection Prevention Cheat Sheet</a></li>
+</ul>]]></references>
+ <vulnerabilityClassifications><![CDATA[<ul>
+<li><a href="https://cwe.mitre.org/data/definitions/89.html">CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')</a></li>
+<li><a href="https://cwe.mitre.org/data/definitions/94.html">CWE-94: Improper Control of Generation of Code ('Code Injection')
+</a></li>
+<li><a href="https://cwe.mitre.org/data/definitions/116.html">CWE-116: Improper Encoding or Escaping of Output</a></li>
+</ul>]]></vulnerabilityClassifications>
+ <issueDetail><![CDATA[The <b>sort_direction</b> parameter appears to be vulnerable to SQL injection attacks. The payload <b>,(select*from(select(sleep(20)))a)</b> was submitted in the sort_direction parameter. The application took <b>20314</b> milliseconds to respond to the request, compared with <b>1980</b> milliseconds for the original request, indicating that the injected SQL command caused a time delay.<br><br>The database appears to be MySQL.]]></issueDetail>
+ <requestresponse>
+ <request method="GET" base64="true"><![CDATA[R0VUIC9jb21tb24vdXNlcl9wcm9maWxlLnBocD9JRD01NDkmdGFibGVfaWQ9dXBfYXNzaWduZWRfZGV2aWNlc190YWJsZSZzb3J0X2NvbHVtbj1JU19QUklNQVJZX0RFVklDRSZzb3J0X2RpcmVjdGlvbj1kZXNjJTJjKHNlbGVjdCpmcm9tKHNlbGVjdChzbGVlcCgyMCkpKWEpJnJlY29yZHNfcGVyX3BhZ2U9NSZwYWdlX251bWJlcj0xIEhUVFAvMS4xDQpIb3N0OiBrYWNlLm5hYmFuY2FyZC5jb20NClVzZXItQWdlbnQ6IE1vemlsbGEvNS4wIChNYWNpbnRvc2g7IEludGVsIE1hYyBPUyBYIDEwLjEyOyBydjo1Ni4wKSBHZWNrby8yMDEwMDEwMSBGaXJlZm94LzU2LjANCkFjY2VwdDogYXBwbGljYXRpb24vanNvbiwgdGV4dC9qYXZhc2NyaXB0LCAqLyo7IHE9MC4wMQ0KQWNjZXB0LUxhbmd1YWdlOiBlbi1VUyxlbjtxPTAuNQ0KQWNjZXB0LUVuY29kaW5nOiBnemlwLCBkZWZsYXRlDQpSZWZlcmVyOiBodHRwczovL2thY2UubmFiYW5jYXJkLmNvbS91c2VydWkvYWR2aXNvcnlfZGV0YWlsLnBocD9JRD0xJTIwKyUyMDENClgtUmVxdWVzdGVkLVdpdGg6IFhNTEh0dHBSZXF1ZXN0DQpDb29raWU6IGtib3hpZD1lbWkzbmZtaDUyMW82OWE1dGQ5bHY3M2ViNjsgS0FDRV9DU1JGX1RPS0VOPTMyZWIxOTg3MmU3NTYwYWExNjMyYzQ5ODc2OTEwYzUwYjdiOTMwMDY5YWRkOGYwNDIzYjBlNzVjYjY3YjRiYjdkM2U3MDMyMWRiY2U0MDRhYjEzZTU0NjkwNmY2ZWM5ODAwY2RjYzRjMTZmZWEwYWNiMjBhN2FmNTdjNDRkNzkzOyBLQUNFX0xBU1RfVVNFUl9TRUNVUkU9JTlDJTlFJTA3JTkwJUEwJUM5JUUzJUVDJTBCJTFEJUIwJTgyJUIzJThGJTg2cDsgS0FDRV9MQVNUX09SR19TRUNVUkU9JURFJUEzJTBFMjAlOEUlODQlQkYlQjElRDUlODklRTAlQTglRTYlMkElRkQ7IHgtZGVsbC1hdXRoLWp3dD1leUowZVhBaU9pSktWMVFpTENKaGJHY2lPaUpTVXpJMU5pSjkuZXlKcGMzTWlPaUpCVFZOSlpHVnVkR2wwZVZCeWIzWnBaR1Z5SWl3aWMzVmlJam8xTkRFc0ltRjFaQ0k2SWtWVFRWQnNZWFJtYjNKdElpd2lZMjl1SWpvaVkyVTBaak5qT0RZeE5EWTBORGxqTVRnM056YzBPV1l3TXpjNE5qVmlPRFVpTENKbGVIQWlPakUxTVRBeE9EUTROalY5LlNCcl9rSUwwdVJYQ0RVYV9WdzVGM2NMRVRXalJ6NlI1VlZYSlpPYUpjT2FqYUJla2Q4RW5xM3FSU0FhdXY1TmVQR0NQOWRra3JHQ0JUWjZqeHlMZ19HOEM1MV9iekl0ckM2OS1meFZZLXlqaGNPX1dlSi1MREpITGRPbVhaWm1oQ1NWSmhyTHJ1blNJc0xESmJ3cHFGV0ZhRGJtN05KWWM5NXMxcGU3a1FnMDsgS0FDRV9MQVNUX0FETUlOX1NFQ1VSRT0lOUMlOUUlMDclOTAlQTAlQzklRTMlRUMlMEIlMUQlQjAlODIlQjMlOEYlODZwDQpDb25uZWN0aW9uOiBjbG9zZQ0KDQo=]]></request>
+ <response base64="true"><![CDATA[SFRUUC8xLjEgMjAwIE9LDQpEYXRlOiBXZWQsIDA4IE5vdiAyMDE3IDE5OjUyOjI2IEdNVA0KU2VydmVyOiBBcGFjaGUNCkV4cGlyZXM6IFRodSwgMTkgTm92IDE5ODEgMDg6NTI6MDAgR01UDQpDYWNoZS1Db250cm9sOiBuby1zdG9yZSwgbm8tY2FjaGUsIG11c3QtcmV2YWxpZGF0ZSwgcG9zdC1jaGVjaz0wLCBwcmUtY2hlY2s9MA0KUHJhZ21hOiBuby1jYWNoZQ0KVmFyeTogQWNjZXB0LUVuY29kaW5nDQpBY2Nlc3MtQ29udHJvbC1BbGxvdy1IZWFkZXJzOiB4LWRlbGwtYXV0aC10aW1lc3RhbXAsIHgtZGVsbC1hdXRoLWtleSwgeC1kZWxsLWF1dGgtc2lnbmF0dXJlLCBhY2NlcHQsIG9yaWdpbiwgY29udGVudC10eXBlDQpBY2Nlc3MtQ29udHJvbC1BbGxvdy1PcmlnaW46ICoNCkFjY2Vzcy1Db250cm9sLUFsbG93LU1ldGhvZHM6IFBVVCwgREVMRVRFLCBQT1NULCBHRVQsIE9QVElPTlMNClgtRGVsbEtBQ0UtQXBwbGlhbmNlOiBrMTAwMA0KWC1EZWxsS0FDRS1Ib3N0OiBLQUNFLm5hYmFuY2FyZC5jb20NClgtRGVsbEtBQ0UtVmVyc2lvbjogNy4yLjEwMg0KWC1LQk9YLVdlYlNlcnZlcjogS0FDRS5uYWJhbmNhcmQuY29tDQpYLUtCT1gtVmVyc2lvbjogNy4yLjEwMg0KWC1LQUNFLUFwcGxpYW5jZTogSzEwMDANClgtS0FDRS1Ib3N0OiBLQUNFLm5hYmFuY2FyZC5jb20NClgtS0FDRS1WZXJzaW9uOiA3LjIuMTAyDQpYLUtBQ0UtV2ViU2VydmVyOiBLQUNFLm5hYmFuY2FyZC5jb20NClgtVUEtQ29tcGF0aWJsZTogSUU9OSxFREdFDQpDYWNoZS1Db250cm9sOiBwcml2YXRlLCBuby1jYWNoZSwgbm8tc3RvcmUsIHByb3h5LXJldmFsaWRhdGUsIG5vLXRyYW5zZm9ybQ0KQ29udGVudC1MZW5ndGg6IDQ0DQpDb25uZWN0aW9uOiBjbG9zZQ0KQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgNClN0cmljdC1UcmFuc3BvcnQtU2VjdXJpdHk6IG1heC1hZ2U9MTU3NjgwMDANCg0KeyJjdXJyZW50X3BhZ2UiOjEsInRvdGFsX3BhZ2VzIjowLCJyb3dzIjpbXX0=]]></response>
+ <responseRedirected>false</responseRedirected>
+ </requestresponse>
+ </issue>
+ <issue>
+ <serialNumber>2096392919560836096</serialNumber>
+ <type>2098688</type>
+ <name><![CDATA[Cross-origin resource sharing]]></name>
+ <host ip="198.252.230.171">https://kace.nabancard.com</host>
+ <path><![CDATA[/common/user_profile.php]]></path>
+ <location><![CDATA[/common/user_profile.php]]></location>
+ <severity>Information</severity>
+ <confidence>Certain</confidence>
+ <issueBackground><![CDATA[<p>An HTML5 cross-origin resource sharing (CORS) policy controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy. The policy is fine-grained and can apply access controls per-request based on the URL and other features of the request.</p><p>If another domain is allowed by the policy, then that domain can potentially attack users of the application. If a user is logged in to the application, and visits a domain allowed by the policy, then any malicious content running on that domain can potentially retrieve content from the application, and sometimes carry out actions within the security context of the logged in user.</p>
+<p>Even if an allowed domain is not overtly malicious in itself, security vulnerabilities within that domain could potentially be leveraged by an attacker to exploit the trust relationship and attack the application that allows access. CORS policies on pages containing sensitive information should be reviewed to determine whether it is appropriate for the application to trust both the intentions and security posture of any domains granted access.</p>]]></issueBackground>
+ <remediationBackground><![CDATA[<p>Any inappropriate domains should be removed from the CORS policy.</p>]]></remediationBackground>
+ <references><![CDATA[<ul>
+ <li> <a href="http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html">Exploiting CORS Misconfigurations</a> </li>
+</ul>]]></references>
+ <vulnerabilityClassifications><![CDATA[<ul>
+<li><a href="https://cwe.mitre.org/data/definitions/942.html">CWE-942: Overly Permissive Cross-domain Whitelist</a></li>
+</ul>]]></vulnerabilityClassifications>
+ <issueDetail><![CDATA[The application implements an HTML5 cross-origin resource sharing (CORS) policy for this request.<br><br>If the application relies on network firewalls or other IP-based access controls, this policy is likely to present a security risk.<br><br>Since the Vary: Origin header was not present in the response, reverse proxies and intermediate servers may cache it. This may enable an attacker to carry out cache poisoning attacks.]]></issueDetail>
+ <requestresponse>
+ <request method="GET" base64="true"><![CDATA[R0VUIC9jb21tb24vdXNlcl9wcm9maWxlLnBocD9JRD01NDkmdGFibGVfaWQ9dXBfYXNzaWduZWRfZGV2aWNlc190YWJsZSZzb3J0X2NvbHVtbj1JU19QUklNQVJZX0RFVklDRSZzb3J0X2RpcmVjdGlvbj1kZXNjJnJlY29yZHNfcGVyX3BhZ2U9NSZwYWdlX251bWJlcj0xIEhUVFAvMS4xDQpIb3N0OiBrYWNlLm5hYmFuY2FyZC5jb20NClVzZXItQWdlbnQ6IE1vemlsbGEvNS4wIChNYWNpbnRvc2g7IEludGVsIE1hYyBPUyBYIDEwLjEyOyBydjo1Ni4wKSBHZWNrby8yMDEwMDEwMSBGaXJlZm94LzU2LjANCkFjY2VwdDogYXBwbGljYXRpb24vanNvbiwgdGV4dC9qYXZhc2NyaXB0LCAqLyo7IHE9MC4wMQ0KQWNjZXB0LUxhbmd1YWdlOiBlbi1VUyxlbjtxPTAuNQ0KQWNjZXB0LUVuY29kaW5nOiBnemlwLCBkZWZsYXRlDQpSZWZlcmVyOiBodHRwczovL2thY2UubmFiYW5jYXJkLmNvbS91c2VydWkvYWR2aXNvcnlfZGV0YWlsLnBocD9JRD0xJTIwKyUyMDENClgtUmVxdWVzdGVkLVdpdGg6IFhNTEh0dHBSZXF1ZXN0DQpDb29raWU6IGtib3hpZD1lbWkzbmZtaDUyMW82OWE1dGQ5bHY3M2ViNjsgS0FDRV9DU1JGX1RPS0VOPTMyZWIxOTg3MmU3NTYwYWExNjMyYzQ5ODc2OTEwYzUwYjdiOTMwMDY5YWRkOGYwNDIzYjBlNzVjYjY3YjRiYjdkM2U3MDMyMWRiY2U0MDRhYjEzZTU0NjkwNmY2ZWM5ODAwY2RjYzRjMTZmZWEwYWNiMjBhN2FmNTdjNDRkNzkzOyBLQUNFX0xBU1RfVVNFUl9TRUNVUkU9JTlDJTlFJTA3JTkwJUEwJUM5JUUzJUVDJTBCJTFEJUIwJTgyJUIzJThGJTg2cDsgS0FDRV9MQVNUX09SR19TRUNVUkU9JURFJUEzJTBFMjAlOEUlODQlQkYlQjElRDUlODklRTAlQTglRTYlMkElRkQ7IHgtZGVsbC1hdXRoLWp3dD1leUowZVhBaU9pSktWMVFpTENKaGJHY2lPaUpTVXpJMU5pSjkuZXlKcGMzTWlPaUpCVFZOSlpHVnVkR2wwZVZCeWIzWnBaR1Z5SWl3aWMzVmlJam8xTkRFc0ltRjFaQ0k2SWtWVFRWQnNZWFJtYjNKdElpd2lZMjl1SWpvaVkyVTBaak5qT0RZeE5EWTBORGxqTVRnM056YzBPV1l3TXpjNE5qVmlPRFVpTENKbGVIQWlPakUxTVRBeE9EUTROalY5LlNCcl9rSUwwdVJYQ0RVYV9WdzVGM2NMRVRXalJ6NlI1VlZYSlpPYUpjT2FqYUJla2Q4RW5xM3FSU0FhdXY1TmVQR0NQOWRra3JHQ0JUWjZqeHlMZ19HOEM1MV9iekl0ckM2OS1meFZZLXlqaGNPX1dlSi1MREpITGRPbVhaWm1oQ1NWSmhyTHJ1blNJc0xESmJ3cHFGV0ZhRGJtN05KWWM5NXMxcGU3a1FnMDsgS0FDRV9MQVNUX0FETUlOX1NFQ1VSRT0lOUMlOUUlMDclOTAlQTAlQzklRTMlRUMlMEIlMUQlQjAlODIlQjMlOEYlODZwDQpDb25uZWN0aW9uOiBjbG9zZQ0KDQo=]]></request>
+ <response base64="true"><![CDATA[SFRUUC8xLjEgMjAwIE9LDQpEYXRlOiBXZWQsIDA4IE5vdiAyMDE3IDE5OjQ4OjM5IEdNVA0KU2VydmVyOiBBcGFjaGUNCkV4cGlyZXM6IFRodSwgMTkgTm92IDE5ODEgMDg6NTI6MDAgR01UDQpDYWNoZS1Db250cm9sOiBuby1zdG9yZSwgbm8tY2FjaGUsIG11c3QtcmV2YWxpZGF0ZSwgcG9zdC1jaGVjaz0wLCBwcmUtY2hlY2s9MA0KUHJhZ21hOiBuby1jYWNoZQ0KVmFyeTogQWNjZXB0LUVuY29kaW5nDQpBY2Nlc3MtQ29udHJvbC1BbGxvdy1IZWFkZXJzOiB4LWRlbGwtYXV0aC10aW1lc3RhbXAsIHgtZGVsbC1hdXRoLWtleSwgeC1kZWxsLWF1dGgtc2lnbmF0dXJlLCBhY2NlcHQsIG9yaWdpbiwgY29udGVudC10eXBlDQpBY2Nlc3MtQ29udHJvbC1BbGxvdy1PcmlnaW46ICoNCkFjY2Vzcy1Db250cm9sLUFsbG93LU1ldGhvZHM6IFBVVCwgREVMRVRFLCBQT1NULCBHRVQsIE9QVElPTlMNClgtRGVsbEtBQ0UtQXBwbGlhbmNlOiBrMTAwMA0KWC1EZWxsS0FDRS1Ib3N0OiBLQUNFLm5hYmFuY2FyZC5jb20NClgtRGVsbEtBQ0UtVmVyc2lvbjogNy4yLjEwMg0KWC1LQk9YLVdlYlNlcnZlcjogS0FDRS5uYWJhbmNhcmQuY29tDQpYLUtCT1gtVmVyc2lvbjogNy4yLjEwMg0KWC1LQUNFLUFwcGxpYW5jZTogSzEwMDANClgtS0FDRS1Ib3N0OiBLQUNFLm5hYmFuY2FyZC5jb20NClgtS0FDRS1WZXJzaW9uOiA3LjIuMTAyDQpYLUtBQ0UtV2ViU2VydmVyOiBLQUNFLm5hYmFuY2FyZC5jb20NClgtVUEtQ29tcGF0aWJsZTogSUU9OSxFREdFDQpDYWNoZS1Db250cm9sOiBwcml2YXRlLCBuby1jYWNoZSwgbm8tc3RvcmUsIHByb3h5LXJldmFsaWRhdGUsIG5vLXRyYW5zZm9ybQ0KQ29udGVudC1MZW5ndGg6IDQ0DQpDb25uZWN0aW9uOiBjbG9zZQ0KQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgNClN0cmljdC1UcmFuc3BvcnQtU2VjdXJpdHk6IG1heC1hZ2U9MTU3NjgwMDANCg0KeyJjdXJyZW50X3BhZ2UiOjEsInRvdGFsX3BhZ2VzIjowLCJyb3dzIjpbXX0=]]></response>
+ <responseRedirected>false</responseRedirected>
+ </requestresponse>
+ </issue>
+ <issue>
+ <serialNumber>450331590754026496</serialNumber>
+ <type>2098688</type>
+ <name><![CDATA[Cross-origin resource sharing]]></name>
+ <host ip="198.252.230.171">https://kace.nabancard.com</host>
+ <path><![CDATA[/common/user_profile.php]]></path>
+ <location><![CDATA[/common/user_profile.php]]></location>
+ <severity>Information</severity>
+ <confidence>Certain</confidence>
+ <issueBackground><![CDATA[<p>An HTML5 cross-origin resource sharing (CORS) policy controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy. The policy is fine-grained and can apply access controls per-request based on the URL and other features of the request.</p><p>If another domain is allowed by the policy, then that domain can potentially attack users of the application. If a user is logged in to the application, and visits a domain allowed by the policy, then any malicious content running on that domain can potentially retrieve content from the application, and sometimes carry out actions within the security context of the logged in user.</p>
+<p>Even if an allowed domain is not overtly malicious in itself, security vulnerabilities within that domain could potentially be leveraged by an attacker to exploit the trust relationship and attack the application that allows access. CORS policies on pages containing sensitive information should be reviewed to determine whether it is appropriate for the application to trust both the intentions and security posture of any domains granted access.</p>]]></issueBackground>
+ <remediationBackground><![CDATA[<p>Any inappropriate domains should be removed from the CORS policy.</p>]]></remediationBackground>
+ <references><![CDATA[<ul>
+ <li> <a href="http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html">Exploiting CORS Misconfigurations</a> </li>
+</ul>]]></references>
+ <vulnerabilityClassifications><![CDATA[<ul>
+<li><a href="https://cwe.mitre.org/data/definitions/942.html">CWE-942: Overly Permissive Cross-domain Whitelist</a></li>
+</ul>]]></vulnerabilityClassifications>
+ <issueDetail><![CDATA[The application implements an HTML5 cross-origin resource sharing (CORS) policy for this request.<br><br>If the application relies on network firewalls or other IP-based access controls, this policy is likely to present a security risk.<br><br>Since the Vary: Origin header was not present in the response, reverse proxies and intermediate servers may cache it. This may enable an attacker to carry out cache poisoning attacks.]]></issueDetail>
+ <requestresponse>
+ <request method="GET" base64="true"><![CDATA[R0VUIC9jb21tb24vdXNlcl9wcm9maWxlLnBocD9JRD01NDkmdGFibGVfaWQ9dXBfYXNzaWduZWRfZGV2aWNlc190YWJsZSZzb3J0X2NvbHVtbj1JU19QUklNQVJZX0RFVklDRSZzb3J0X2RpcmVjdGlvbj1kZXNjJnJlY29yZHNfcGVyX3BhZ2U9NSZwYWdlX251bWJlcj0xIEhUVFAvMS4xDQpIb3N0OiBrYWNlLm5hYmFuY2FyZC5jb20NClVzZXItQWdlbnQ6IE1vemlsbGEvNS4wIChNYWNpbnRvc2g7IEludGVsIE1hYyBPUyBYIDEwLjEyOyBydjo1Ni4wKSBHZWNrby8yMDEwMDEwMSBGaXJlZm94LzU2LjANCkFjY2VwdDogYXBwbGljYXRpb24vanNvbiwgdGV4dC9qYXZhc2NyaXB0LCAqLyo7IHE9MC4wMQ0KQWNjZXB0LUxhbmd1YWdlOiBlbi1VUyxlbjtxPTAuNQ0KQWNjZXB0LUVuY29kaW5nOiBnemlwLCBkZWZsYXRlDQpSZWZlcmVyOiBodHRwczovL2thY2UubmFiYW5jYXJkLmNvbS91c2VydWkvYWR2aXNvcnlfZGV0YWlsLnBocD9JRD0xJTIwKyUyMDENClgtUmVxdWVzdGVkLVdpdGg6IFhNTEh0dHBSZXF1ZXN0DQpDb29raWU6IGtib3hpZD00ZDJ0bzdodmN1N21hNGZidDdlN2FkMHQ1MTsgS0FDRV9DU1JGX1RPS0VOPTU4ZDQ5ZDIwMTY4MjMwNWUzOTZjZGFiZTMyOWYxZjUyOGE1NmFkYTkyZWNiZDk0NDM1ZmY5NGMyYzY4Y2E0ZmY2ZmI1NjE4ZDhiYzhmOTU3NmNkMmYzNzQ4ZjQ2Y2UzMTY3Y2Y2MGRhZWVjNDAwYjQ4MTc4YWYxZWI4Mjc1NDA5OyBLQUNFX0xBU1RfVVNFUl9TRUNVUkU9JTlDJTlFJTA3JTkwJUEwJUM5JUUzJUVDJTBCJTFEJUIwJTgyJUIzJThGJTg2cDsgS0FDRV9MQVNUX09SR19TRUNVUkU9JURFJUEzJTBFMjAlOEUlODQlQkYlQjElRDUlODklRTAlQTglRTYlMkElRkQ7IHgtZGVsbC1hdXRoLWp3dD1leUowZVhBaU9pSktWMVFpTENKaGJHY2lPaUpTVXpJMU5pSjkuZXlKcGMzTWlPaUpCVFZOSlpHVnVkR2wwZVZCeWIzWnBaR1Z5SWl3aWMzVmlJam8xTkRFc0ltRjFaQ0k2SWtWVFRWQnNZWFJtYjNKdElpd2lZMjl1SWpvaVkyVTBaak5qT0RZeE5EWTBORGxqTVRnM056YzBPV1l3TXpjNE5qVmlPRFVpTENKbGVIQWlPakUxTVRBeE9EVTFNamg5LktqdC1mbFlKMm5DMjJiRXp0V20xVFZiajFERjN0UkFCbU8zNzYyQTYtYmllY1QtZllLVzJCVGNOaTZXQzFva2d6V3pHSXFucnVac05hbS1OaXNDQk54WjJzU3dDakZPXzBEUjN4YzBQUXQwLXJJVTBZLWxnNTBZY09PQXk2MTFuSEtxazBERzBZb2ZxNWFPUUtPWGtxcXlZdmdpVUxfc3I0WmdaRkNjLU52czsgS0FDRV9MQVNUX0FETUlOX1NFQ1VSRT0lOUMlOUUlMDclOTAlQTAlQzklRTMlRUMlMEIlMUQlQjAlODIlQjMlOEYlODZwOyBrYm94X25hdj0xDQpDb25uZWN0aW9uOiBjbG9zZQ0KT3JpZ2luOiBodHRwczovL2thY2UubmFiYW5jYXJkLmNvbQ0KDQo=]]></request>
+ <response base64="true"><![CDATA[SFRUUC8xLjEgMjAwIE9LDQpEYXRlOiBXZWQsIDA4IE5vdiAyMDE3IDIwOjAxOjM1IEdNVA0KU2VydmVyOiBBcGFjaGUNCkV4cGlyZXM6IFRodSwgMTkgTm92IDE5ODEgMDg6NTI6MDAgR01UDQpDYWNoZS1Db250cm9sOiBuby1zdG9yZSwgbm8tY2FjaGUsIG11c3QtcmV2YWxpZGF0ZSwgcG9zdC1jaGVjaz0wLCBwcmUtY2hlY2s9MA0KUHJhZ21hOiBuby1jYWNoZQ0KVmFyeTogQWNjZXB0LUVuY29kaW5nDQpBY2Nlc3MtQ29udHJvbC1BbGxvdy1IZWFkZXJzOiB4LWRlbGwtYXV0aC10aW1lc3RhbXAsIHgtZGVsbC1hdXRoLWtleSwgeC1kZWxsLWF1dGgtc2lnbmF0dXJlLCBhY2NlcHQsIG9yaWdpbiwgY29udGVudC10eXBlDQpBY2Nlc3MtQ29udHJvbC1BbGxvdy1PcmlnaW46ICoNCkFjY2Vzcy1Db250cm9sLUFsbG93LU1ldGhvZHM6IFBVVCwgREVMRVRFLCBQT1NULCBHRVQsIE9QVElPTlMNClgtRGVsbEtBQ0UtQXBwbGlhbmNlOiBrMTAwMA0KWC1EZWxsS0FDRS1Ib3N0OiBLQUNFLm5hYmFuY2FyZC5jb20NClgtRGVsbEtBQ0UtVmVyc2lvbjogNy4yLjEwMg0KWC1LQk9YLVdlYlNlcnZlcjogS0FDRS5uYWJhbmNhcmQuY29tDQpYLUtCT1gtVmVyc2lvbjogNy4yLjEwMg0KWC1LQUNFLUFwcGxpYW5jZTogSzEwMDANClgtS0FDRS1Ib3N0OiBLQUNFLm5hYmFuY2FyZC5jb20NClgtS0FDRS1WZXJzaW9uOiA3LjIuMTAyDQpYLUtBQ0UtV2ViU2VydmVyOiBLQUNFLm5hYmFuY2FyZC5jb20NClgtVUEtQ29tcGF0aWJsZTogSUU9OSxFREdFDQpDYWNoZS1Db250cm9sOiBwcml2YXRlLCBuby1jYWNoZSwgbm8tc3RvcmUsIHByb3h5LXJldmFsaWRhdGUsIG5vLXRyYW5zZm9ybQ0KQ29udGVudC1MZW5ndGg6IDQ0DQpDb25uZWN0aW9uOiBjbG9zZQ0KQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgNClN0cmljdC1UcmFuc3BvcnQtU2VjdXJpdHk6IG1heC1hZ2U9MTU3NjgwMDANCg0KeyJjdXJyZW50X3BhZ2UiOjEsInRvdGFsX3BhZ2VzIjowLCJyb3dzIjpbXX0=]]></response>
+ <responseRedirected>false</responseRedirected>
+ </requestresponse>
+ </issue>
+ <issue>
+ <serialNumber>6870999518795599872</serialNumber>
+ <type>2098689</type>
+ <name><![CDATA[Cross-origin resource sharing: arbitrary origin trusted]]></name>
+ <host ip="198.252.230.171">https://kace.nabancard.com</host>
+ <path><![CDATA[/common/user_profile.php]]></path>
+ <location><![CDATA[/common/user_profile.php]]></location>
+ <severity>Information</severity>
+ <confidence>Certain</confidence>
+ <issueBackground><![CDATA[<p>An HTML5 cross-origin resource sharing (CORS) policy controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy. The policy is fine-grained and can apply access controls per-request based on the URL and other features of the request.</p><p>
+Trusting arbitrary origins effectively disables the same-origin policy, allowing two-way interaction by third-party web sites. Unless the response consists only of unprotected public content, this policy is likely to present a security risk.</p>
+<p>If the site specifies the header Access-Control-Allow-Credentials: true, third-party sites may be able to carry out privileged actions and retrieve sensitive information. Even if it does not, attackers may be able to bypass any IP-based access controls by proxying through users' browsers.</p>]]></issueBackground>
+ <remediationBackground><![CDATA[<p>Rather than using a wildcard or programmatically verifying supplied origins, use a whitelist of trusted domains.</p>]]></remediationBackground>
+ <references><![CDATA[<ul>
+ <li> <a href="http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html">Exploiting CORS Misconfigurations</a> </li>
+</ul>]]></references>
+ <vulnerabilityClassifications><![CDATA[<ul>
+<li><a href="https://cwe.mitre.org/data/definitions/942.html">CWE-942: Overly Permissive Cross-domain Whitelist</a></li>
+</ul>]]></vulnerabilityClassifications>
+ <issueDetail><![CDATA[The application implements an HTML5 cross-origin resource sharing (CORS) policy for this request that allows access from any domain.<br><br>The application allowed access from the requested origin <strong>https://pfcxuvwamstc.com</strong><br><br>If the application relies on network firewalls or other IP-based access controls, this policy is likely to present a security risk.<br><br>Since the Vary: Origin header was not present in the response, reverse proxies and intermediate servers may cache it. This may enable an attacker to carry out cache poisoning attacks.]]></issueDetail>
+ <requestresponse>
+ <request method="GET" base64="true"><![CDATA[R0VUIC9jb21tb24vdXNlcl9wcm9maWxlLnBocD9JRD01NDkmdGFibGVfaWQ9dXBfYXNzaWduZWRfZGV2aWNlc190YWJsZSZzb3J0X2NvbHVtbj1JU19QUklNQVJZX0RFVklDRSZzb3J0X2RpcmVjdGlvbj1kZXNjJnJlY29yZHNfcGVyX3BhZ2U9NSZwYWdlX251bWJlcj0xIEhUVFAvMS4xDQpIb3N0OiBrYWNlLm5hYmFuY2FyZC5jb20NClVzZXItQWdlbnQ6IE1vemlsbGEvNS4wIChNYWNpbnRvc2g7IEludGVsIE1hYyBPUyBYIDEwLjEyOyBydjo1Ni4wKSBHZWNrby8yMDEwMDEwMSBGaXJlZm94LzU2LjANCkFjY2VwdDogYXBwbGljYXRpb24vanNvbiwgdGV4dC9qYXZhc2NyaXB0LCAqLyo7IHE9MC4wMQ0KQWNjZXB0LUxhbmd1YWdlOiBlbi1VUyxlbjtxPTAuNQ0KQWNjZXB0LUVuY29kaW5nOiBnemlwLCBkZWZsYXRlDQpSZWZlcmVyOiBodHRwczovL2thY2UubmFiYW5jYXJkLmNvbS91c2VydWkvYWR2aXNvcnlfZGV0YWlsLnBocD9JRD0xJTIwKyUyMDENClgtUmVxdWVzdGVkLVdpdGg6IFhNTEh0dHBSZXF1ZXN0DQpDb29raWU6IGtib3hpZD00ZDJ0bzdodmN1N21hNGZidDdlN2FkMHQ1MTsgS0FDRV9DU1JGX1RPS0VOPTU4ZDQ5ZDIwMTY4MjMwNWUzOTZjZGFiZTMyOWYxZjUyOGE1NmFkYTkyZWNiZDk0NDM1ZmY5NGMyYzY4Y2E0ZmY2ZmI1NjE4ZDhiYzhmOTU3NmNkMmYzNzQ4ZjQ2Y2UzMTY3Y2Y2MGRhZWVjNDAwYjQ4MTc4YWYxZWI4Mjc1NDA5OyBLQUNFX0xBU1RfVVNFUl9TRUNVUkU9JTlDJTlFJTA3JTkwJUEwJUM5JUUzJUVDJTBCJTFEJUIwJTgyJUIzJThGJTg2cDsgS0FDRV9MQVNUX09SR19TRUNVUkU9JURFJUEzJTBFMjAlOEUlODQlQkYlQjElRDUlODklRTAlQTglRTYlMkElRkQ7IHgtZGVsbC1hdXRoLWp3dD1leUowZVhBaU9pSktWMVFpTENKaGJHY2lPaUpTVXpJMU5pSjkuZXlKcGMzTWlPaUpCVFZOSlpHVnVkR2wwZVZCeWIzWnBaR1Z5SWl3aWMzVmlJam8xTkRFc0ltRjFaQ0k2SWtWVFRWQnNZWFJtYjNKdElpd2lZMjl1SWpvaVkyVTBaak5qT0RZeE5EWTBORGxqTVRnM056YzBPV1l3TXpjNE5qVmlPRFVpTENKbGVIQWlPakUxTVRBeE9EVTFNamg5LktqdC1mbFlKMm5DMjJiRXp0V20xVFZiajFERjN0UkFCbU8zNzYyQTYtYmllY1QtZllLVzJCVGNOaTZXQzFva2d6V3pHSXFucnVac05hbS1OaXNDQk54WjJzU3dDakZPXzBEUjN4YzBQUXQwLXJJVTBZLWxnNTBZY09PQXk2MTFuSEtxazBERzBZb2ZxNWFPUUtPWGtxcXlZdmdpVUxfc3I0WmdaRkNjLU52czsgS0FDRV9MQVNUX0FETUlOX1NFQ1VSRT0lOUMlOUUlMDclOTAlQTAlQzklRTMlRUMlMEIlMUQlQjAlODIlQjMlOEYlODZwOyBrYm94X25hdj0xDQpDb25uZWN0aW9uOiBjbG9zZQ0KT3JpZ2luOiBodHRwczovL3BmY3h1dndhbXN0Yy5jb20NCg0K]]></request>
+ <response base64="true"><![CDATA[SFRUUC8xLjEgMjAwIE9LDQpEYXRlOiBXZWQsIDA4IE5vdiAyMDE3IDIwOjAxOjM2IEdNVA0KU2VydmVyOiBBcGFjaGUNCkV4cGlyZXM6IFRodSwgMTkgTm92IDE5ODEgMDg6NTI6MDAgR01UDQpDYWNoZS1Db250cm9sOiBuby1zdG9yZSwgbm8tY2FjaGUsIG11c3QtcmV2YWxpZGF0ZSwgcG9zdC1jaGVjaz0wLCBwcmUtY2hlY2s9MA0KUHJhZ21hOiBuby1jYWNoZQ0KVmFyeTogQWNjZXB0LUVuY29kaW5nDQpBY2Nlc3MtQ29udHJvbC1BbGxvdy1IZWFkZXJzOiB4LWRlbGwtYXV0aC10aW1lc3RhbXAsIHgtZGVsbC1hdXRoLWtleSwgeC1kZWxsLWF1dGgtc2lnbmF0dXJlLCBhY2NlcHQsIG9yaWdpbiwgY29udGVudC10eXBlDQpBY2Nlc3MtQ29udHJvbC1BbGxvdy1PcmlnaW46ICoNCkFjY2Vzcy1Db250cm9sLUFsbG93LU1ldGhvZHM6IFBVVCwgREVMRVRFLCBQT1NULCBHRVQsIE9QVElPTlMNClgtRGVsbEtBQ0UtQXBwbGlhbmNlOiBrMTAwMA0KWC1EZWxsS0FDRS1Ib3N0OiBLQUNFLm5hYmFuY2FyZC5jb20NClgtRGVsbEtBQ0UtVmVyc2lvbjogNy4yLjEwMg0KWC1LQk9YLVdlYlNlcnZlcjogS0FDRS5uYWJhbmNhcmQuY29tDQpYLUtCT1gtVmVyc2lvbjogNy4yLjEwMg0KWC1LQUNFLUFwcGxpYW5jZTogSzEwMDANClgtS0FDRS1Ib3N0OiBLQUNFLm5hYmFuY2FyZC5jb20NClgtS0FDRS1WZXJzaW9uOiA3LjIuMTAyDQpYLUtBQ0UtV2ViU2VydmVyOiBLQUNFLm5hYmFuY2FyZC5jb20NClgtVUEtQ29tcGF0aWJsZTogSUU9OSxFREdFDQpDYWNoZS1Db250cm9sOiBwcml2YXRlLCBuby1jYWNoZSwgbm8tc3RvcmUsIHByb3h5LXJldmFsaWRhdGUsIG5vLXRyYW5zZm9ybQ0KQ29udGVudC1MZW5ndGg6IDQ0DQpDb25uZWN0aW9uOiBjbG9zZQ0KQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgNClN0cmljdC1UcmFuc3BvcnQtU2VjdXJpdHk6IG1heC1hZ2U9MTU3NjgwMDANCg0KeyJjdXJyZW50X3BhZ2UiOjEsInRvdGFsX3BhZ2VzIjowLCJyb3dzIjpbXX0=]]></response>
+ <responseRedirected>false</responseRedirected>
+ </requestresponse>
+ </issue>
+</issues>
diff --git a/examples/reports/junit_dojo.xml b/examples/reports/junit_dojo.xml
new file mode 100644
index 0000000000000000000000000000000000000000..642ff46957b3820c726bc518ffca51221884fe9b
--- /dev/null
+++ b/examples/reports/junit_dojo.xml
@@ -0,0 +1,97 @@
+<?xml version="1.0" ?>
+<testsuite failures="4" name="DefectDojo" tests="4">
+ <testcase name="blacklist Severity: Info">
+ <failure>Using cElementTree to parse untrusted XML data is known to be vulnerable to XML attacks. Replace cElementTree with the equivalent defusedxml package, or make sure defusedxml.defuse_stdlib() is called. Filename: PyBitBucket.py Line number: 6 Line range: [6, 7, 8, 9] Issue Confidence: HIGH</failure>
+ </testcase>
+ <testcase name="SQL injection Severity: High">
+ <failure>SQL injection vulnerabilities arise when user-controllable data is
+incorporated into database SQL queries in an unsafe manner. An attacker can
+supply crafted input to break out of the data context in which their input
+appears and interfere with the structure of the surrounding query.
+
+A wide range of damaging attacks can often be delivered via SQL injection,
+including reading or modifying critical application data, interfering with
+application logic, escalating privileges within the database and taking
+control of the database server.
+
+
+
+The **sort_column** parameter appears to be vulnerable to SQL injection
+attacks. The payload **,(select*from(select(sleep(20)))a)** was submitted in
+the sort_column parameter. The application took **20562** milliseconds to
+respond to the request, compared with **1980** milliseconds for the original
+request, indicating that the injected SQL command caused a time delay.
+
+The database appears to be MySQL.
+
+</failure>
+ </testcase>
+ <testcase name="Cross-origin resource sharing Severity: Info">
+ <failure>An HTML5 cross-origin resource sharing (CORS) policy controls whether and how
+content running on other domains can perform two-way interaction with the
+domain that publishes the policy. The policy is fine-grained and can apply
+access controls per-request based on the URL and other features of the
+request.
+
+If another domain is allowed by the policy, then that domain can potentially
+attack users of the application. If a user is logged in to the application,
+and visits a domain allowed by the policy, then any malicious content running
+on that domain can potentially retrieve content from the application, and
+sometimes carry out actions within the security context of the logged in user.
+
+Even if an allowed domain is not overtly malicious in itself, security
+vulnerabilities within that domain could potentially be leveraged by an
+attacker to exploit the trust relationship and attack the application that
+allows access. CORS policies on pages containing sensitive information should
+be reviewed to determine whether it is appropriate for the application to
+trust both the intentions and security posture of any domains granted access.
+
+
+
+The application implements an HTML5 cross-origin resource sharing (CORS)
+policy for this request.
+
+If the application relies on network firewalls or other IP-based access
+controls, this policy is likely to present a security risk.
+
+Since the Vary: Origin header was not present in the response, reverse proxies
+and intermediate servers may cache it. This may enable an attacker to carry
+out cache poisoning attacks.
+
+</failure>
+ </testcase>
+ <testcase name="Cross-origin resource sharing: arbitrary origin trusted Severity: Info">
+ <failure>An HTML5 cross-origin resource sharing (CORS) policy controls whether and how
+content running on other domains can perform two-way interaction with the
+domain that publishes the policy. The policy is fine-grained and can apply
+access controls per-request based on the URL and other features of the
+request.
+
+Trusting arbitrary origins effectively disables the same-origin policy,
+allowing two-way interaction by third-party web sites. Unless the response
+consists only of unprotected public content, this policy is likely to present
+a security risk.
+
+If the site specifies the header Access-Control-Allow-Credentials: true,
+third-party sites may be able to carry out privileged actions and retrieve
+sensitive information. Even if it does not, attackers may be able to bypass
+any IP-based access controls by proxying through users' browsers.
+
+
+
+The application implements an HTML5 cross-origin resource sharing (CORS)
+policy for this request that allows access from any domain.
+
+The application allowed access from the requested origin
+**https://pfcxuvwamstc.com**
+
+If the application relies on network firewalls or other IP-based access
+controls, this policy is likely to present a security risk.
+
+Since the Vary: Origin header was not present in the response, reverse proxies
+and intermediate servers may cache it. This may enable an attacker to carry
+out cache poisoning attacks.
+
+</failure>
+ </testcase>
+</testsuite>