vrt 0.8.1 → 0.9.0
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/lib/data/1.8/deprecated-node-mapping.json +149 -0
- data/lib/data/1.8/mappings/cvss_v3/cvss_v3.json +935 -0
- data/lib/data/1.8/mappings/cvss_v3/cvss_v3.schema.json +59 -0
- data/lib/data/1.8/mappings/cwe/cwe.json +453 -0
- data/lib/data/1.8/mappings/cwe/cwe.schema.json +63 -0
- data/lib/data/1.8/mappings/remediation_advice/remediation_advice.json +1381 -0
- data/lib/data/1.8/mappings/remediation_advice/remediation_advice.schema.json +75 -0
- data/lib/data/1.8/vrt.schema.json +63 -0
- data/lib/data/1.8/vulnerability-rating-taxonomy.json +1948 -0
- data/lib/vrt/version.rb +1 -1
- metadata +11 -2
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "http://json-schema.org/draft-04/schema#",
|
|
3
|
+
"title": "VRT to CWE Mapping",
|
|
4
|
+
"description": "Mapping from the Vulnerability Rating Taxonomy to CWE",
|
|
5
|
+
"definitions": {
|
|
6
|
+
"MappingMetadata": {
|
|
7
|
+
"type": "object",
|
|
8
|
+
"properties": {
|
|
9
|
+
"default": { "type": "null" }
|
|
10
|
+
},
|
|
11
|
+
"required": ["default"]
|
|
12
|
+
},
|
|
13
|
+
"VRTid": { "type": "string", "pattern": "^[a-z_]*$" },
|
|
14
|
+
"CWE": { "type" : [ "array", "null" ],
|
|
15
|
+
"items" : { "type": "string", "pattern": "^CWE-[0-9]*$" },
|
|
16
|
+
"minItems": 1,
|
|
17
|
+
"uniqueItems": true
|
|
18
|
+
},
|
|
19
|
+
"Mapping": {
|
|
20
|
+
"type": "object",
|
|
21
|
+
"properties": {
|
|
22
|
+
"id": { "$ref": "#/definitions/VRTid" },
|
|
23
|
+
"cwe" : { "$ref": "#/definitions/CWE" }
|
|
24
|
+
},
|
|
25
|
+
"required": ["id", "cwe"],
|
|
26
|
+
"additionalProperties": false
|
|
27
|
+
},
|
|
28
|
+
"MappingParent": {
|
|
29
|
+
"type": "object",
|
|
30
|
+
"properties": {
|
|
31
|
+
"id": { "$ref": "#/definitions/VRTid" },
|
|
32
|
+
"children": {
|
|
33
|
+
"type": "array",
|
|
34
|
+
"items" : {
|
|
35
|
+
"anyOf": [
|
|
36
|
+
{ "$ref": "#/definitions/MappingParent" },
|
|
37
|
+
{ "$ref": "#/definitions/Mapping" }
|
|
38
|
+
]
|
|
39
|
+
}
|
|
40
|
+
},
|
|
41
|
+
"cwe" : { "$ref": "#/definitions/CWE" }
|
|
42
|
+
},
|
|
43
|
+
"required": ["id", "children"],
|
|
44
|
+
"additionalProperties": false
|
|
45
|
+
}
|
|
46
|
+
},
|
|
47
|
+
"type": "object",
|
|
48
|
+
"required": ["metadata", "content"],
|
|
49
|
+
"properties": {
|
|
50
|
+
"metadata": {
|
|
51
|
+
"$ref": "#/definitions/MappingMetadata"
|
|
52
|
+
},
|
|
53
|
+
"content": {
|
|
54
|
+
"type": "array",
|
|
55
|
+
"items" : {
|
|
56
|
+
"anyOf": [
|
|
57
|
+
{ "$ref": "#/definitions/MappingParent" },
|
|
58
|
+
{ "$ref": "#/definitions/Mapping" }
|
|
59
|
+
]
|
|
60
|
+
}
|
|
61
|
+
}
|
|
62
|
+
}
|
|
63
|
+
}
|
|
@@ -0,0 +1,1381 @@
|
|
|
1
|
+
{
|
|
2
|
+
"metadata": {
|
|
3
|
+
"default": null,
|
|
4
|
+
"keys": ["remediation_advice", "references"]
|
|
5
|
+
},
|
|
6
|
+
"content": [
|
|
7
|
+
{
|
|
8
|
+
"id": "server_security_misconfiguration",
|
|
9
|
+
"references": [
|
|
10
|
+
"https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration",
|
|
11
|
+
"http://projects.webappsec.org/w/page/13246959/Server%20Misconfiguration"
|
|
12
|
+
],
|
|
13
|
+
"children": [
|
|
14
|
+
{
|
|
15
|
+
"id": "unsafe_cross_origin_resource_sharing",
|
|
16
|
+
"remediation_advice": "1. **Origin & Access-Control-Allow-Origin:** The Origin header is always sent by the browser in a `CORS` request and indicates the origin of the request. The Origin header can not be changed from JavaScript however relying on this header for Access Control checks is not a good idea as it may be spoofed outside the browser, so you still need to check that application-level protocols are used to protect sensitive data.\n2. **Access-Control-Allow-Origin** is a response header used by a server to indicate which domains are allowed to read the response. Based on the `CORS W3 Specification` it is up to the client to determine and enforce the restriction of whether the client has access to the response data based on this header.\n3. Make sure that there are no insecure configurations using a wildcard as value which looks like `Access-Control-Allow-Origin: *` as this header means all domains are allowed access to the resource. \n4. Make sure that when the server returns back the Origin header that there are additional checks so that access of sensitive data is not allowed.\n5. The `Access-Control-Request-Method` header is used when a browser performs a preflight `OPTIONS` request and let the client indicate the request method of the final request. On the other hand, the `Access-Control-Allow-Method` is a response header used by the server to describe the methods the clients are allowed to use.\n6. **Access-Control-Request-Headers & Access-Control-Allow-Headers:** These two headers are used between the browser and the server to determine which headers can be used to perform a cross-origin request.\n7. **Access-Control-Allow-Credentials:** This header as part of a preflight request indicates that the final request can include user credentials.\n8. **Input validation:** XMLHttpRequest L2 (or XHR L2) introduces the possibility of creating a cross-domain request using the XHR API for backwards compatibility. This can introduce security vulnerabilities that in XHR L1 were not present. Interesting points of the code to exploit would be URLs that are passed to XMLHttpRequest without validation, specially if absolute URLS are allowed because that could lead to code injection. Likewise, other part of the application that can be exploited is if the response data is not escaped and we can control it by providing user-supplied input.\n9. **Other headers:** There are other headers involved like Access-Control-Max-Age that determines the time a preflight request can be cached in the browser, or Access-Control-Expose-Headers that indicates which headers are safe to expose to the API of a CORS API specification, both are response headers specified in the CORS W3C document.",
|
|
17
|
+
"references": [
|
|
18
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/HTML5_Security_Cheat_Sheet.md#cross-origin-resource-sharing",
|
|
19
|
+
"https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS"
|
|
20
|
+
]
|
|
21
|
+
},
|
|
22
|
+
{
|
|
23
|
+
"id": "path_traversal",
|
|
24
|
+
"remediation_advice": "1. Prefer working without user input when using file system calls\n2. Use indexes rather than actual portions of file names when templating or using language files (i.e. value 5 from the user submission = Czechoslovakian, rather than expecting the user to return “Czechoslovakian”)\n3. Ensure the user cannot supply all parts of the path – surround it with your path code\n4. Validate the user’s input by only accepting known good – do not sanitize the data\n5. Use `chroot`ed jails and code access policies to restrict where the files can be obtained or saved to\n6. If forced to use user input for file operations, normalize the input before using in file I/O APIs, such as the [Java SE URI normalize() method](http://docs.oracle.com/javase/7/docs/api/java/net/URI.html#normalize).",
|
|
25
|
+
"references": [
|
|
26
|
+
"https://www.owasp.org/index.php/Path_Traversal",
|
|
27
|
+
"https://www.owasp.org/index.php/File_System#Path_traversal",
|
|
28
|
+
"http://projects.webappsec.org/w/page/13246952/Path%20Traversal"
|
|
29
|
+
]
|
|
30
|
+
},
|
|
31
|
+
{
|
|
32
|
+
"id": "directory_listing_enabled",
|
|
33
|
+
"remediation_advice": "Restrict directory listings being displayed from the server configuration. \n\nExample for Apache:\n\n1. Edit the server configuration file or edit/create directory .htaccess\n2. Add the following line:\nOptions -Indexes\n3. If it is the last line, make sure you have a new line after it.",
|
|
34
|
+
"references": [
|
|
35
|
+
"http://projects.webappsec.org/w/page/13246922/Directory%20Indexing"
|
|
36
|
+
]
|
|
37
|
+
},
|
|
38
|
+
{
|
|
39
|
+
"id": "same_site_scripting",
|
|
40
|
+
"remediation_advice": "As a best practice, do not resolve targets or hostnames to 127.0.0.1 or similar addresses.",
|
|
41
|
+
"references": [
|
|
42
|
+
"http://seclists.org/bugtraq/2008/Jan/270"
|
|
43
|
+
]
|
|
44
|
+
},
|
|
45
|
+
{
|
|
46
|
+
"id": "ssl_attack_breach_poodle_etc",
|
|
47
|
+
"remediation_advice": "Disable SSL and use updated version of TLS that is not susceptible to the latest variation of the TLS attack.",
|
|
48
|
+
"references": [
|
|
49
|
+
"https://access.redhat.com/articles/1232123",
|
|
50
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.md",
|
|
51
|
+
"http://projects.webappsec.org/w/page/13246945/Insufficient%20Transport%20Layer%20Protection"
|
|
52
|
+
]
|
|
53
|
+
},
|
|
54
|
+
{
|
|
55
|
+
"id": "using_default_credentials",
|
|
56
|
+
"remediation_advice": "1. If possible consider disabling external access.\n2. Never use default credentials as it is trivial for an attacker to gain access by providing known or easy to guess credentials.\n3. Always change any kind of default credentials as the first step of setting up any kind of environment.\n4. Passwords should meet or exceed proper password strength requirements.",
|
|
57
|
+
"references": [
|
|
58
|
+
"https://www.owasp.org/index.php/Testing_for_default_credentials_(OTG-AUTHN-002)",
|
|
59
|
+
"https://www.owasp.org/index.php/Configuration#Default_passwords",
|
|
60
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md"
|
|
61
|
+
]
|
|
62
|
+
},
|
|
63
|
+
{
|
|
64
|
+
"id": "misconfigured_dns",
|
|
65
|
+
"children": [
|
|
66
|
+
{
|
|
67
|
+
"id": "basic_subdomain_takeover",
|
|
68
|
+
"remediation_advice": "1. Set up your external service so it fully listens to your wildcard DNS.\n2. Keep your DNS-entries constantly vetted and restricted.",
|
|
69
|
+
"references": [
|
|
70
|
+
"https://labs.detectify.com/2014/10/21/hostile-subdomain-takeover-using-herokugithubdesk-more/"
|
|
71
|
+
]
|
|
72
|
+
},
|
|
73
|
+
{
|
|
74
|
+
"id": "high_impact_subdomain_takeover",
|
|
75
|
+
"remediation_advice": "1. Set up your external service so it fully listens to your wildcard DNS.\n2. Keep your DNS-entries constantly vetted and restricted.",
|
|
76
|
+
"references": [
|
|
77
|
+
"https://labs.detectify.com/2014/10/21/hostile-subdomain-takeover-using-herokugithubdesk-more/"
|
|
78
|
+
]
|
|
79
|
+
},
|
|
80
|
+
{
|
|
81
|
+
"id": "zone_transfer",
|
|
82
|
+
"remediation_advice": "Do not allow DNS zone transfers.",
|
|
83
|
+
"references": [
|
|
84
|
+
"https://www.sans.org/reading-room/whitepapers/dns/securing-dns-zone-transfer-868",
|
|
85
|
+
"https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-1999-0532"
|
|
86
|
+
]
|
|
87
|
+
},
|
|
88
|
+
{
|
|
89
|
+
"id": "missing_caa_record",
|
|
90
|
+
"remediation_advice": "As the domain name holder you can modify the DNS zone file to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain.",
|
|
91
|
+
"references": [
|
|
92
|
+
"https://tools.ietf.org/html/rfc6844"
|
|
93
|
+
]
|
|
94
|
+
}
|
|
95
|
+
]
|
|
96
|
+
},
|
|
97
|
+
{
|
|
98
|
+
"id": "mail_server_misconfiguration",
|
|
99
|
+
"children": [
|
|
100
|
+
{
|
|
101
|
+
"id": "no_spoofing_protection_on_email_domain",
|
|
102
|
+
"remediation_advice": "Create a DMARC policy to prevent email spoofing. Please note that if your DMARC policy is not set up properly it may result in email delivery issues.",
|
|
103
|
+
"references": [
|
|
104
|
+
"https://mxtoolbox.com/DMARCRecordGenerator.aspx",
|
|
105
|
+
"https://dmarc.org/2016/03/best-practices-for-email-senders/",
|
|
106
|
+
"https://www.ftc.gov/system/files/documents/reports/businesses-can-help-stop-phishing-protect-their-brands-using-email-authentication-ftc-staff/email_authentication_staff_perspective.pdf"
|
|
107
|
+
]
|
|
108
|
+
},
|
|
109
|
+
{
|
|
110
|
+
"id": "email_spoofing_to_inbox_due_to_missing_or_misconfigured_dmarc_on_email_domain",
|
|
111
|
+
"remediation_advice": "SPF is not a sufficient email spoofing protection in case of some of the largest email providers. Emails spoofed for domains having properly configured hard fail SPF records may still be delivered to the recipient's inbox. In order to fully prevent email spoofing create a DMARC record with “p=reject” policy. Please note that if your DMARC policy is not set up properly it may result in email delivery issues.",
|
|
112
|
+
"references": [
|
|
113
|
+
"https://mxtoolbox.com/DMARCRecordGenerator.aspx",
|
|
114
|
+
"https://dmarc.org/2016/03/best-practices-for-email-senders/",
|
|
115
|
+
"https://www.ftc.gov/system/files/documents/reports/businesses-can-help-stop-phishing-protect-their-brands-using-email-authentication-ftc-staff/email_authentication_staff_perspective.pdf"
|
|
116
|
+
]
|
|
117
|
+
},
|
|
118
|
+
{
|
|
119
|
+
"id": "email_spoofing_to_spam_folder",
|
|
120
|
+
"remediation_advice": "In order to fully prevent email spoofing create a DMARC record with “p=reject” policy. Please note that if your DMARC policy is not set up properly it will result in email delivery issues.",
|
|
121
|
+
"references": [
|
|
122
|
+
"https://dmarc.org/wiki/FAQ#My_mail_is_going_to_the_spam_folder_now.2C_is_DMARC_the_problem.3F",
|
|
123
|
+
"https://mxtoolbox.com/DMARCRecordGenerator.aspx",
|
|
124
|
+
"http://www.openspf.org/SPF_Record_Syntax"
|
|
125
|
+
]
|
|
126
|
+
},
|
|
127
|
+
{
|
|
128
|
+
"id": "missing_or_misconfigured_spf_and_or_dkim",
|
|
129
|
+
"remediation_advice": "1. Consider adding email spoofing protections for all your domains as attackers may resort to spoofing those, regardless of whether emails originate from them or not. Victims can still be fooled by seeing your domain.\n2. Consider using -all instead of ~all in the SPF record. Please be aware that using -all may result in email delivery issues.\n3. Since there is a limit of 10 DNS lookups per SPF record, specifying an IP address or address range is preferable for long lists of outgoing mail servers.",
|
|
130
|
+
"references": [
|
|
131
|
+
"http://www.openspf.org/SPF_Record_Syntax",
|
|
132
|
+
"http://www.openspf.org/FAQ/Common_mistakes#include"
|
|
133
|
+
]
|
|
134
|
+
},
|
|
135
|
+
{
|
|
136
|
+
"id": "email_spoofing_on_non_email_domain",
|
|
137
|
+
"remediation_advice": "Consider adding email spoofing protections for all your domains as attackers may resort to spoofing those, regardless of whether emails originate from them or not. Victims can still be fooled by seeing your domain.",
|
|
138
|
+
"references": [
|
|
139
|
+
"https://mxtoolbox.com/DMARCRecordGenerator.aspx",
|
|
140
|
+
"https://dmarc.org/2016/03/best-practices-for-email-senders/",
|
|
141
|
+
"https://www.ftc.gov/system/files/documents/reports/businesses-can-help-stop-phishing-protect-their-brands-using-email-authentication-ftc-staff/email_authentication_staff_perspective.pdf"
|
|
142
|
+
]
|
|
143
|
+
}
|
|
144
|
+
]
|
|
145
|
+
},
|
|
146
|
+
{
|
|
147
|
+
"id": "dbms_misconfiguration",
|
|
148
|
+
"children": [
|
|
149
|
+
{
|
|
150
|
+
"id": "excessively_privileged_user_dba",
|
|
151
|
+
"remediation_advice": "Ensure that the current DBMS session user has the least amount of privilege necessary.",
|
|
152
|
+
"references": [
|
|
153
|
+
"https://www.owasp.org/index.php/Least_privilege"
|
|
154
|
+
]
|
|
155
|
+
}
|
|
156
|
+
]
|
|
157
|
+
},
|
|
158
|
+
{
|
|
159
|
+
"id": "lack_of_password_confirmation",
|
|
160
|
+
"children": [
|
|
161
|
+
{
|
|
162
|
+
"id": "change_email_address",
|
|
163
|
+
"remediation_advice": "1. Use a password confirmation if the email address associated with the account is going to be changed.\n2. As a best practice, send the original email address a confirmation that the email address on their account is being changed. Have the user confirm that they want to change their email address as well as prompting the user for their password."
|
|
164
|
+
},
|
|
165
|
+
{
|
|
166
|
+
"id": "change_password",
|
|
167
|
+
"remediation_advice": "Use a password confirmation if the original password associated with the account is going to be changed."
|
|
168
|
+
},
|
|
169
|
+
{
|
|
170
|
+
"id": "delete_account",
|
|
171
|
+
"remediation_advice": "Use a password confirmation if there is a request to delete the account."
|
|
172
|
+
},
|
|
173
|
+
{
|
|
174
|
+
"id": "manage_two_fa",
|
|
175
|
+
"remediation_advice": "Use a password confirmation when managing 2FA settings."
|
|
176
|
+
}
|
|
177
|
+
]
|
|
178
|
+
},
|
|
179
|
+
{
|
|
180
|
+
"id": "no_rate_limiting_on_form",
|
|
181
|
+
"references": [
|
|
182
|
+
"https://www.owasp.org/index.php?title=OWASP_Periodic_Table_of_Vulnerabilities_-_Brute_Force_(Generic)_/_Insufficient_Anti-automation&setlang=en",
|
|
183
|
+
"http://projects.webappsec.org/w/page/13246938/Insufficient%20Anti-automation"
|
|
184
|
+
],
|
|
185
|
+
"children": [
|
|
186
|
+
{
|
|
187
|
+
"id": "registration",
|
|
188
|
+
"remediation_advice": "1. Use a `CAPTCHA` to limit user registration requests.\n2. Use a rate limit per IP address to throttle the amount of user registration requests that can be made in a certain amount of time."
|
|
189
|
+
},
|
|
190
|
+
{
|
|
191
|
+
"id": "login",
|
|
192
|
+
"remediation_advice": "1. Use a `CAPTCHA` to limit login attempts.\n2. Use a rate limit per IP address to throttle the amount of login requests that can be made in a certain amount of time.\n3. Be careful about locking a user account out as a result of rate limiting."
|
|
193
|
+
},
|
|
194
|
+
{
|
|
195
|
+
"id": "email_triggering",
|
|
196
|
+
"remediation_advice": "1. Use a `CAPTCHA` to limit email triggering requests.\n2. Use a rate limit per IP address to throttle the amount of email triggering requests that can be made in a certain amount of time."
|
|
197
|
+
},
|
|
198
|
+
{
|
|
199
|
+
"id": "sms_triggering",
|
|
200
|
+
"remediation_advice": "1. Use a `CAPTCHA` to limit SMS triggering requests.\n2. Use a rate limit per IP address to throttle the amount of SMS triggering requests that can be made in a certain amount of time."
|
|
201
|
+
}
|
|
202
|
+
]
|
|
203
|
+
},
|
|
204
|
+
{
|
|
205
|
+
"id": "unsafe_file_upload",
|
|
206
|
+
"references": [
|
|
207
|
+
"https://www.owasp.org/index.php/Unrestricted_File_Upload",
|
|
208
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Protect_FileUpload_Against_Malicious_File.md"
|
|
209
|
+
],
|
|
210
|
+
"children": [
|
|
211
|
+
{
|
|
212
|
+
"id": "no_antivirus",
|
|
213
|
+
"remediation_advice": "As a best practice, consider using endpoint protection to check uploaded files for malware and viruses."
|
|
214
|
+
},
|
|
215
|
+
{
|
|
216
|
+
"id": "no_size_limit",
|
|
217
|
+
"remediation_advice": "Have a server-side check for the size limit of file uploads."
|
|
218
|
+
},
|
|
219
|
+
{
|
|
220
|
+
"id": "file_extension_filter_bypass",
|
|
221
|
+
"remediation_advice": "As a best practice, consider using a whitelist of accepted file extensions in order to mitigate against a bypass."
|
|
222
|
+
}
|
|
223
|
+
]
|
|
224
|
+
},
|
|
225
|
+
{
|
|
226
|
+
"id": "cookie_scoped_to_parent_domain",
|
|
227
|
+
"remediation_advice": "If possible do not set the domain for the session cookie. If domain is not set, so by default, the cookie will be a host only cookie, meaning accessible explicitly to the domain from which it was set.",
|
|
228
|
+
"references": [
|
|
229
|
+
"https://tools.ietf.org/html/rfc6265"
|
|
230
|
+
]
|
|
231
|
+
},
|
|
232
|
+
{
|
|
233
|
+
"id": "missing_secure_or_httponly_cookie_flag",
|
|
234
|
+
"references": [
|
|
235
|
+
"https://www.owasp.org/index.php/SecureFlag",
|
|
236
|
+
"https://www.owasp.org/index.php/HttpOnly"
|
|
237
|
+
],
|
|
238
|
+
"children": [
|
|
239
|
+
{
|
|
240
|
+
"id": "session_token",
|
|
241
|
+
"remediation_advice": "Set the `Secure` and `HTTPOnly` cookie flags for the session token."
|
|
242
|
+
},
|
|
243
|
+
{
|
|
244
|
+
"id": "non_session_cookie",
|
|
245
|
+
"remediation_advice": "Consider setting the `Secure` and `HTTPOnly` cookie flags for sensitive cookies."
|
|
246
|
+
}
|
|
247
|
+
]
|
|
248
|
+
},
|
|
249
|
+
{
|
|
250
|
+
"id": "clickjacking",
|
|
251
|
+
"references": [
|
|
252
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Clickjacking_Defense_Cheat_Sheet.md",
|
|
253
|
+
"https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#xfo_bp"
|
|
254
|
+
],
|
|
255
|
+
"children": [
|
|
256
|
+
{
|
|
257
|
+
"id": "sensitive_action",
|
|
258
|
+
"remediation_advice": "1. Use the `X-Frame-Options: DENY` HTTP response header on pages with sensitive information, to disallow framing of the page on external resources.\n2. In the case where `DENY` is not an option, use `X-Frame-Options: SAMEORIGIN`.\n3. In the case where `SAMEORIGIN` is not an option, `X-Frame-Options: ALLOW-FROM https://example.com/`."
|
|
259
|
+
},
|
|
260
|
+
{
|
|
261
|
+
"id": "form_input",
|
|
262
|
+
"remediation_advice": "1. Use the `X-Frame-Options: DENY` HTTP response header on pages with sensitive information, to disallow framing of the page on external resources.\n2. In the case where `DENY` is not an option, use `X-Frame-Options: SAMEORIGIN`.\n3. In the case where `SAMEORIGIN` is not an option, `X-Frame-Options: ALLOW-FROM https://example.com/`."
|
|
263
|
+
},
|
|
264
|
+
{
|
|
265
|
+
"id": "non_sensitive_action",
|
|
266
|
+
"remediation_advice": "As a best practice, consider adding the `X-FRAME-OPTIONS: SAMEORIGIN` HTTP response header to all responses going to the user's browser to avoid unnecessary cross-origin iframe access."
|
|
267
|
+
}
|
|
268
|
+
]
|
|
269
|
+
},
|
|
270
|
+
{
|
|
271
|
+
"id": "oauth_misconfiguration",
|
|
272
|
+
"children": [
|
|
273
|
+
{
|
|
274
|
+
"id": "account_takeover",
|
|
275
|
+
"remediation_advice": "Ensure correct implementation of OAuth protocol in order to protect client secrets and tokens, and provide secure access controls.",
|
|
276
|
+
"references": [
|
|
277
|
+
"https://tools.ietf.org/html/rfc6819"
|
|
278
|
+
]
|
|
279
|
+
},
|
|
280
|
+
{
|
|
281
|
+
"id": "missing_state_parameter",
|
|
282
|
+
"remediation_advice": "The OAuth state parameter is a form of CSRF protection, ensure that it is in place and properly validated."
|
|
283
|
+
},
|
|
284
|
+
{
|
|
285
|
+
"id": "insecure_redirect_uri",
|
|
286
|
+
"remediation_advice": "When the application starts the OAuth flow, it will direct the user to your service’s authorization endpoint. The request will have several parameters in the URL, including a redirect URL.\n\nAt this point, the authorization server must validate the redirect URL to ensure the URL in the request matches one of the registered URLs for the application. The request will also have a client_id parameter, so the service should look up the redirect URLs based on that. It is entirely possible for an attacker to craft an authorization request with one app’s client ID and the attacker’s redirect URL, which is why registration is required.\n\nThe service should look for an exact match of the URL, and avoid matching on only part of the specific URL. (The client can use the state parameter if it needs to customize each request.) Simple string matching is sufficient since the redirect URL can’t be customized per request. All the server needs to do is check that the redirect URL in the request matches one of the redirect URLs the developer entered when registering their application.\n\nIf the redirect URL is not one of the registered redirect URLs, then the server must immediately show an error indicating such, and not redirect the user. This avoids having your authorization server be used as an open redirector.",
|
|
287
|
+
"references": [
|
|
288
|
+
"https://www.oauth.com/oauth2-servers/redirect-uris/"
|
|
289
|
+
]
|
|
290
|
+
}
|
|
291
|
+
]
|
|
292
|
+
},
|
|
293
|
+
{
|
|
294
|
+
"id": "captcha",
|
|
295
|
+
"children": [
|
|
296
|
+
{
|
|
297
|
+
"id": "implementation_vulnerability",
|
|
298
|
+
"remediation_advice": "1. Introduce a proper server-side check for the `CAPTCHA`.\n2. Make sure that the user input matches the `CAPTCHA`.\n3. Make sure that the `CAPTCHA` is difficult to solve by computers."
|
|
299
|
+
},
|
|
300
|
+
{
|
|
301
|
+
"id": "brute_force",
|
|
302
|
+
"remediation_advice": "As a best practice, consider disallowing multiple attempts to guess the same CAPTCHA."
|
|
303
|
+
},
|
|
304
|
+
{
|
|
305
|
+
"id": "missing",
|
|
306
|
+
"remediation_advice": "As a best practice, consider using CAPTCHAs to prevent automated software from engaging in abusive activities on your site."
|
|
307
|
+
}
|
|
308
|
+
]
|
|
309
|
+
},
|
|
310
|
+
{
|
|
311
|
+
"id": "exposed_admin_portal",
|
|
312
|
+
"children": [
|
|
313
|
+
{
|
|
314
|
+
"id": "to_internet",
|
|
315
|
+
"remediation_advice": "As a best practice, consider restricting admin portal access to internal users only."
|
|
316
|
+
}
|
|
317
|
+
]
|
|
318
|
+
},
|
|
319
|
+
{
|
|
320
|
+
"id": "missing_dnssec",
|
|
321
|
+
"remediation_advice": "As a best practice, consider utilizing the Domain Name System Security Extensions, as this will help the DNS protocol to be less susceptible to certain attacks.",
|
|
322
|
+
"references": [
|
|
323
|
+
"https://www.icann.org/resources/pages/dnssec-qaa-2014-01-29-en"
|
|
324
|
+
]
|
|
325
|
+
},
|
|
326
|
+
{
|
|
327
|
+
"id": "fingerprinting_banner_disclosure",
|
|
328
|
+
"remediation_advice": "As a best practice, do not expose the specific software version."
|
|
329
|
+
},
|
|
330
|
+
{
|
|
331
|
+
"id": "username_enumeration",
|
|
332
|
+
"children": [
|
|
333
|
+
{
|
|
334
|
+
"id": "brute_force",
|
|
335
|
+
"remediation_advice": "Login: When an authentication request fails, ensure that all responses are identical, regardless of whether it was the username or the password that caused the authentication to fail. The HTTP response needs to be the same as well. There should not be a single byte or bit difference.\n\nReset Password: There can not be a discrepancy in the form responses when using the reset a password functionality. The same message should be sent, back to the user, regardless of whether the username or email exists as an account or not.\n\nRegistration: As a best practice to prevent usernames from being enumerated when creating an account, the username should be an email address. When an attempt is made to create a new user account, the same message can be displayed regardless of whether the email address exists in the system or not. For example: \"A confirmation has been sent to the email provided.\"",
|
|
336
|
+
"references": [
|
|
337
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md#authentication-and-error-messages"
|
|
338
|
+
]
|
|
339
|
+
}
|
|
340
|
+
]
|
|
341
|
+
},
|
|
342
|
+
{
|
|
343
|
+
"id": "potentially_unsafe_http_method_enabled",
|
|
344
|
+
"references": [
|
|
345
|
+
"https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006)"
|
|
346
|
+
],
|
|
347
|
+
"children": [
|
|
348
|
+
{
|
|
349
|
+
"id": "options",
|
|
350
|
+
"remediation_advice": "As a best practice, consider turning off the `OPTIONS` HTTP request method, unless absolutely necessary. The OPTIONS method provides a list of the methods that are supported by the web server."
|
|
351
|
+
},
|
|
352
|
+
{
|
|
353
|
+
"id": "trace",
|
|
354
|
+
"remediation_advice": "As a best practice, consider turning off the `TRACE` HTTP request method unless absolutely necessary. Doing so will mitigate against potential Cross Site Tracing attacks.",
|
|
355
|
+
"references": [
|
|
356
|
+
"https://www.owasp.org/index.php/Cross_Site_Tracing"
|
|
357
|
+
]
|
|
358
|
+
}
|
|
359
|
+
]
|
|
360
|
+
},
|
|
361
|
+
{
|
|
362
|
+
"id": "insecure_ssl",
|
|
363
|
+
"children": [
|
|
364
|
+
{
|
|
365
|
+
"id": "lack_of_forward_secrecy",
|
|
366
|
+
"remediation_advice": "As a best practice, consider using Forward Secrecy. This ensures that broad decrypting of recorded HTTPS sessions can not happen, should the private key become publicly accessible.",
|
|
367
|
+
"references": [
|
|
368
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.md#rule---prefer-ephemeral-key-exchanges"
|
|
369
|
+
]
|
|
370
|
+
},
|
|
371
|
+
{
|
|
372
|
+
"id": "insecure_cipher_suite",
|
|
373
|
+
"remediation_advice": "As a best practice, consider supporting only cipher suites that are known to be secure.",
|
|
374
|
+
"references": [
|
|
375
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.md#rule---only-support-strong-cryptographic-ciphers"
|
|
376
|
+
]
|
|
377
|
+
},
|
|
378
|
+
{
|
|
379
|
+
"id": "certificate_error",
|
|
380
|
+
"remediation_advice": "As a best practice, consider resolving any SSL certificate errors in order to establish trust and allow secure connections.",
|
|
381
|
+
"references": [
|
|
382
|
+
"https://cheapsslsecurity.com/blog/google-chrome-ssl-certificate-errors-troubleshoot-guide/"
|
|
383
|
+
]
|
|
384
|
+
}
|
|
385
|
+
]
|
|
386
|
+
},
|
|
387
|
+
{
|
|
388
|
+
"id": "rfd",
|
|
389
|
+
"remediation_advice": "1. Sanitize your API inputs (in this case they should just allow alphanumerics). Escaping is not sufficient.\n2. Add `Content-Disposition: attachment; filename=\"foo.bar\"` on APIs that are not going to be rendered.\n3. Add `X-Content-Type-Options: nosniff` header to API responses.",
|
|
390
|
+
"references": [
|
|
391
|
+
"https://www.owasp.org/index.php/Reflected_File_Download"
|
|
392
|
+
]
|
|
393
|
+
},
|
|
394
|
+
{
|
|
395
|
+
"id": "lack_of_security_headers",
|
|
396
|
+
"children": [
|
|
397
|
+
{
|
|
398
|
+
"id": "x_frame_options",
|
|
399
|
+
"remediation_advice": "As a best practice, consider using the X-Frame-Options header as it will help mitigate against potential Clickjacking or other UI redressing attacks.",
|
|
400
|
+
"references": [
|
|
401
|
+
"https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#xfo_bp",
|
|
402
|
+
"https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options"
|
|
403
|
+
]
|
|
404
|
+
},
|
|
405
|
+
{
|
|
406
|
+
"id": "cache_control_for_a_non_sensitive_page",
|
|
407
|
+
"remediation_advice": "As a best practice, consider using the `Cache-Control: no-cache` as it will help insure that the browser does not cache pages. Although the page may not currently contain sensitive data, sensitive data may be unintentionally placed there in the future.",
|
|
408
|
+
"references": [
|
|
409
|
+
"https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control"
|
|
410
|
+
]
|
|
411
|
+
},
|
|
412
|
+
{
|
|
413
|
+
"id": "x_xss_protection",
|
|
414
|
+
"remediation_advice": "As a best practice, consider using the `X-XSS-Protection` header as it will help ensure browsers that support this header will detect and help mitigate against reflected Cross Site Scripting. It is important to note that this will not completely mitigate against all reflected Cross Site Scripting attacks, but will help prevent many generic injection attacks.",
|
|
415
|
+
"references": [
|
|
416
|
+
"https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#xxxsp_bp",
|
|
417
|
+
"https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection"
|
|
418
|
+
]
|
|
419
|
+
},
|
|
420
|
+
{
|
|
421
|
+
"id": "strict_transport_security",
|
|
422
|
+
"remediation_advice": "As a best practice, consider using the `Strict-Transport-Security` header as it will help ensure protection against TLS protocol downgrade attacks and cookie hijacking. The header also ensures that browsers are only serving requests using a secure HTTPS connection.",
|
|
423
|
+
"references": [
|
|
424
|
+
"https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#hsts",
|
|
425
|
+
"https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security"
|
|
426
|
+
]
|
|
427
|
+
},
|
|
428
|
+
{
|
|
429
|
+
"id": "x_content_type_options",
|
|
430
|
+
"remediation_advice": "As a best practice, consider using the `X-Content-Type-Options: nosniff` header as it will help prevent ambiguous handling of file types via Content Sniffing. Adding this header will prevent Cross Site Scripting attacks on files that do not have an explicit file type of \"text/html\".",
|
|
431
|
+
"references": [
|
|
432
|
+
"https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#xcto",
|
|
433
|
+
"https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options"
|
|
434
|
+
]
|
|
435
|
+
},
|
|
436
|
+
{
|
|
437
|
+
"id": "content_security_policy",
|
|
438
|
+
"remediation_advice": "As a best practice, consider using the `Content-Security-Policy` header as it will help prevent Cross Site Scripting as well as other types of injection attacks. However, be aware that Content Security Policy has a significant impact on how the browser renders pages, so careful tuning is required.",
|
|
439
|
+
"references": [
|
|
440
|
+
"https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#csp",
|
|
441
|
+
"https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy"
|
|
442
|
+
]
|
|
443
|
+
},
|
|
444
|
+
{
|
|
445
|
+
"id": "public_key_pins",
|
|
446
|
+
"remediation_advice": "As a best practice, consider using the `Public-Key-Pins` header as it will help prevent website impersonation by mis-issued or otherwise fraudulent certificates. It is important to note that if this header is used incorrectly, it may prevent users from accessing a resource for an extended period of time.",
|
|
447
|
+
"references": [
|
|
448
|
+
"https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#hpkp",
|
|
449
|
+
"https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Public-Key-Pins"
|
|
450
|
+
]
|
|
451
|
+
},
|
|
452
|
+
{
|
|
453
|
+
"id": "x_content_security_policy",
|
|
454
|
+
"remediation_advice": "As a best practice, consider using the `X-Content-Security-Policy` header as it will help prevent Cross Site Scripting as well as other types of injection attacks. However, be aware that Content Security Policy has a significant impact on how the browser renders pages, so careful tuning is required.",
|
|
455
|
+
"references": [
|
|
456
|
+
"https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#csp",
|
|
457
|
+
"https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy"
|
|
458
|
+
]
|
|
459
|
+
},
|
|
460
|
+
{
|
|
461
|
+
"id": "x_webkit_csp",
|
|
462
|
+
"remediation_advice": "As a best practice, consider using the `X-Webkit-CSP` header as it will help prevent Cross Site Scripting as well as other types of injection attacks. However, be aware that Content Security Policy has a significant impact on how the browser renders pages, so careful tuning is required.",
|
|
463
|
+
"references": [
|
|
464
|
+
"https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#csp",
|
|
465
|
+
"https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy"
|
|
466
|
+
]
|
|
467
|
+
},
|
|
468
|
+
{
|
|
469
|
+
"id": "content_security_policy_report_only",
|
|
470
|
+
"remediation_advice": "As a best practice, consider using the `Content-Security-Policy-Report-Only` header as it will help when testing out the implementation of a Content Security Policy, to prevent Cross Site Scripting as well as other types of injection attacks.",
|
|
471
|
+
"references": [
|
|
472
|
+
"https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#csp",
|
|
473
|
+
"https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy-Report-Only"
|
|
474
|
+
]
|
|
475
|
+
},
|
|
476
|
+
{
|
|
477
|
+
"id": "cache_control_for_a_sensitive_page",
|
|
478
|
+
"remediation_advice": "Add the `Cache-Control` HTTP response header such as `Cache-Control: no-cache`, as it will help insure that the browser does not cache sensitive pages."
|
|
479
|
+
}
|
|
480
|
+
]
|
|
481
|
+
},
|
|
482
|
+
{
|
|
483
|
+
"id": "waf_bypass",
|
|
484
|
+
"children": [
|
|
485
|
+
{
|
|
486
|
+
"id": "direct_server_access",
|
|
487
|
+
"remediation_advice": "To ensure that your origin servers cannot be accessed directly, only accept traffic coming from your Web Application Firewall provider's IP ranges, rather than trusting that your servers remain inaccessible due to their IP's being secret.",
|
|
488
|
+
"references": [
|
|
489
|
+
"https://blog.christophetd.fr/bypassing-cloudflare-using-internet-wide-scan-data/"
|
|
490
|
+
]
|
|
491
|
+
}
|
|
492
|
+
]
|
|
493
|
+
},
|
|
494
|
+
{
|
|
495
|
+
"id": "race_condition",
|
|
496
|
+
"remediation_advice": "The key to preventing a race condition is to find a way to synchronize or otherwise strictly control the order of operations in potentially vulnerable functions and actions. The best way to do this is through locks. Most programming languages have a built-in locking functionality for data; for example, Python has “threading.Lock”, and Go has “sync.Mutex”. Refer to the documentation for your programming language of choice for more information. If the language has multi-threaded or asynchronous capabilities built-in, it should have some form of locking mechanism available to you.",
|
|
497
|
+
"references": [
|
|
498
|
+
"https://lightningsecurity.io/blog/race-conditions/",
|
|
499
|
+
"https://blog.securitycompass.com/moving-beyond-the-owasp-top-10-part-1-race-conditions-912dccbb7c14",
|
|
500
|
+
"https://medium.com/in-the-weeds/fixing-a-race-condition-c8b475fbb994",
|
|
501
|
+
"https://blog.arkency.com/2015/09/testing-race-conditions/",
|
|
502
|
+
"http://www.javacreed.com/what-is-race-condition-and-how-to-prevent-it/",
|
|
503
|
+
"https://blog.golang.org/race-detector"
|
|
504
|
+
]
|
|
505
|
+
},
|
|
506
|
+
{
|
|
507
|
+
"id": "cache_poisoning",
|
|
508
|
+
"remediation_advice": "The most robust defense against cache poisoning is to disable caching. This is plainly unrealistic advice for some, but it's likely that some websites that start using a service like Cloudflare for DDoS protection or easy SSL end up vulnerable to cache poisoning simply because caching is enabled by default.\n\nRestricting caching to purely static responses is also effective, provided you're sufficiently wary about what you define as 'static'.\n\nLikewise, avoiding taking input from headers and cookies is an effective way to prevent cache poisoning, but it's hard to know if other layers and frameworks are sneaking in support for extra headers. You might want to audit every page of your application with Param Miner to flush out unkeyed inputs.\n\nOnce you've identified unkeyed inputs in your application, the ideal solution is to outright disable them. Failing that, you could strip the inputs at the cache layer, or add them to the cache key. Some caches let you use the Vary header to key unkeyed inputs, and others let you define custom cache keys but may restrict this feature to 'enterprise' customers.\n\nFinally, regardless of whether your application has a cache, some of your clients may have a cache at their end and as such client-side vulnerabilities like XSS in HTTP headers should never be ignored.",
|
|
509
|
+
"references": [
|
|
510
|
+
"https://portswigger.net/blog/practical-web-cache-poisoning"
|
|
511
|
+
]
|
|
512
|
+
},
|
|
513
|
+
{
|
|
514
|
+
"id": "bitsquatting",
|
|
515
|
+
"remediation_advice": "As a best practice, consider registering any potential bitsquatting domain names.",
|
|
516
|
+
"references": [
|
|
517
|
+
"http://dinaburg.org/bitsquatting.html"
|
|
518
|
+
]
|
|
519
|
+
}
|
|
520
|
+
]
|
|
521
|
+
},
|
|
522
|
+
{
|
|
523
|
+
"id": "server_side_injection",
|
|
524
|
+
"remediation_advice": "Preventing injection requires keeping untrusted data separate from commands and queries.",
|
|
525
|
+
"references": [
|
|
526
|
+
"https://www.owasp.org/index.php/Top_10-2017_A1-Injection"
|
|
527
|
+
],
|
|
528
|
+
"children": [
|
|
529
|
+
{
|
|
530
|
+
"id": "file_inclusion",
|
|
531
|
+
"remediation_advice": "1. Don't allow user input in file paths. If hard-coding is not an option, select input from a limited list via an index variable.\n2. If dynamic path concatenation is a must have. Only accept required characters. Allow `a-z 0-9` and do not allow `..` or `/` or `%00` (null byte) or any unexpected characters.\n3. For API's allow only inclusion for a specific directory and those below it, this stops traversal attacks.",
|
|
532
|
+
"references": [
|
|
533
|
+
"http://resources.infosecinstitute.com/file-inclusion-attacks/",
|
|
534
|
+
"https://en.wikipedia.org/wiki/File_inclusion_vulnerability",
|
|
535
|
+
"https://www.cvedetails.com/vulnerability-list/opfileinc-1/file-inclusion.html"
|
|
536
|
+
]
|
|
537
|
+
},
|
|
538
|
+
{
|
|
539
|
+
"id": "remote_code_execution_rce",
|
|
540
|
+
"remediation_advice": "The most effective method of eliminating Code Injection vulnerabilities is to avoid code evaluation at all costs unless absolutely and explicitly necessary (i.e. there is no possibility of achieving the same result without code evaluation). In the event where code evaluation is necessary, it is crucial for any user input to be very strongly validated, with as many restrictions as possible on user input.",
|
|
541
|
+
"references": [
|
|
542
|
+
"https://www.owasp.org/index.php/Command_Injection",
|
|
543
|
+
"https://www.cvedetails.com/vulnerability-list/opec-1/execute-code.html"
|
|
544
|
+
]
|
|
545
|
+
},
|
|
546
|
+
{
|
|
547
|
+
"id": "sql_injection",
|
|
548
|
+
"remediation_advice": "Ensure that proper server-side input validation is performed on all sources of user input. Various protections should be implemented using the following in order of effectiveness:\n\n1. **Errors:** Ensure that SQL errors are turned off and not reflected back to a user when an error occurs as to not expose valuable information to an attacker.\n2. **Parameterize Queries:** Ensure that when a user’s input is added to a backend SQL query, it is not string appended but placed into the specific SQL parameter. The method to perform this varies from language to language.\n3. **Server-Side Input Length:** Limit the length of each field depending on its type. For example, a name should be less than **_16 characters long_**, and an ID should be less than **_5 characters long_**.\n4. **Whitelist:** Create character ranges (ie. Numeric, alpha, alphanumeric, alphanumeric with specific characters) and ensure that each input is restricted to the minimum length whitelist necessary.\n5. **Blacklist:** Disallow common injection characters such as `\"<>\\/?*()&`, `SQL` and `SCRIPT` commands such as `SELECT`, `INSERT`, `UPDATE`, `DROP`, and `SCRIPT`, newlines `%0A`, carriage returns `%0D`, null characters `%00` and unnecessary or bad encoding schemas (malformed `ASCII`, `UTF-7`, `UTF-8`, `UTF-16`, `Unicode`, etc.).\n6. **Logging and Web Specific IDS/IPS (Intrusion Detection/Prevention System):** Ensure that proper logging is taking place and is being reviewed, and any malicious traffic which generates an alert is promptly throttled and eventually blacklisted.",
|
|
549
|
+
"references": [
|
|
550
|
+
"https://www.owasp.org/index.php/SQL_Injection",
|
|
551
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.md",
|
|
552
|
+
"http://projects.webappsec.org/SQL-Injection",
|
|
553
|
+
"https://www.cvedetails.com/vulnerability-list/opsqli-1/sql-injection.html"
|
|
554
|
+
]
|
|
555
|
+
},
|
|
556
|
+
{
|
|
557
|
+
"id": "xml_external_entity_injection_xxe",
|
|
558
|
+
"remediation_advice": "Because user supplied XML input comes from an \"untrusted source\" it is very difficult to properly validate the XML document in a manner to prevent against this type of attack. \n\nInstead, the XML processor should be configured to use only locally defined `Document Type Definition (DTD)` and disallow any inline DTD that is specified within user supplied XML documents. \n\nDue to the fact that there are numerous XML parsing engines available for different programming languages, each has its own mechanism for disabling inline DTD to prevent XXE. You may need to search your XML parser's documentation for how to `disable inline DTD` specifically.",
|
|
559
|
+
"references": [
|
|
560
|
+
"https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing",
|
|
561
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.md",
|
|
562
|
+
"http://projects.webappsec.org/XML-External-Entities",
|
|
563
|
+
"https://www.gracefulsecurity.com/xml-external-entity-injection-xxe-vulnerabilities/"
|
|
564
|
+
]
|
|
565
|
+
},
|
|
566
|
+
{
|
|
567
|
+
"id": "http_response_manipulation",
|
|
568
|
+
"children": [
|
|
569
|
+
{
|
|
570
|
+
"id": "response_splitting_crlf",
|
|
571
|
+
"remediation_advice": "Apply proper input validation and check for `CRLF` characters and `null byte` characters whenever user supplied input is used in HTTP response headers.",
|
|
572
|
+
"references": [
|
|
573
|
+
"https://www.owasp.org/index.php/CRLF_Injection",
|
|
574
|
+
"http://projects.webappsec.org/w/page/13246931/HTTP%20Response%20Splitting",
|
|
575
|
+
"https://www.cvedetails.com/vulnerability-list/ophttprs-1/http-response-splitting.html"
|
|
576
|
+
]
|
|
577
|
+
}
|
|
578
|
+
]
|
|
579
|
+
},
|
|
580
|
+
{
|
|
581
|
+
"id": "content_spoofing",
|
|
582
|
+
"remediation_advice": "1. Always treat all user input as untrusted data.\n2. Always input or output encode all data coming into or out of the application.\n3. Always whitelist allowed characters and seldom use blacklisting of characters unless in certain use cases.\n4. Always use a well known and security encoding API for input and output encoding such as the `OWASP ESAPI`.\n5. Never try to write input and output encoders unless absolutely necessary. Chances are that someone has already written a good one.",
|
|
583
|
+
"references": [
|
|
584
|
+
"http://projects.webappsec.org/w/page/13246917/Content%20Spoofing"
|
|
585
|
+
],
|
|
586
|
+
"children": [
|
|
587
|
+
{
|
|
588
|
+
"id": "iframe_injection",
|
|
589
|
+
"references": [
|
|
590
|
+
"http://resources.infosecinstitute.com/iframe-security-risk/"
|
|
591
|
+
]
|
|
592
|
+
},
|
|
593
|
+
{
|
|
594
|
+
"id": "external_authentication_injection",
|
|
595
|
+
"remediation_advice": "Even if unsafe HTML tags like `<script>` or `<iframe>` are filtered out from user input, it is possible to inject `HTTP 401` authentication prompt into a HTML page via tags like `<img>`. In order to prevent this type of injection consider the following solutions:\n\n1. Always treat all user input as untrusted data.\n2. Always input or output encode all data coming into or out of the application.\n3. Always whitelist allowed characters and seldom use blacklisting of characters unless in certain use cases.\n4. Always use a well known and security encoding API for input and output encoding such as the `OWASP ESAPI`.\n5. Never try to write input and output encoders unless absolutely necessary. Chances are that someone has already written a good one.",
|
|
596
|
+
"references": [
|
|
597
|
+
"https://www.exploit-db.com/papers/12898/"
|
|
598
|
+
]
|
|
599
|
+
},
|
|
600
|
+
{
|
|
601
|
+
"id": "flash_based_external_authentication_injection",
|
|
602
|
+
"remediation_advice": "Even if unsafe HTML tags like `<script>` or `<iframe>` are filtered out from user input, it is possible to inject `HTTP 401` authentication prompt into Flash content. In order to prevent this type of injection consider the following solutions:\n\n1. Always treat all user input as untrusted data.\n2. Always input or output encode all data coming into or out of the application.\n3. Always whitelist allowed characters and seldom use blacklisting of characters unless in certain use cases.\n4. Always use a well known and security encoding API for input and output encoding such as the `OWASP ESAPI`.\n5. Never try to write input and output encoders unless absolutely necessary. Chances are that someone has already written a good one."
|
|
603
|
+
},
|
|
604
|
+
{
|
|
605
|
+
"id": "email_html_injection",
|
|
606
|
+
"remediation_advice": "Always ensure that email contents cannot be tampered with. Limit what the user can insert into the email by filtering special characters and limiting the amount of characters that can be inserted. Additionally, filter out any URLs as they are often rendered as links by email providers.",
|
|
607
|
+
"references": [
|
|
608
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Input_Validation_Cheat_Sheet.md"
|
|
609
|
+
]
|
|
610
|
+
},
|
|
611
|
+
{
|
|
612
|
+
"id": "email_hyperlink_injection_based_on_email_provider",
|
|
613
|
+
"remediation_advice": "Always ensure that email contents cannot be tampered with. Limit what the user can insert into the email by filtering special characters and limiting the amount of characters that can be inserted. Filter out any URLs as they are often rendered as links by email providers.",
|
|
614
|
+
"references": [
|
|
615
|
+
"https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet"
|
|
616
|
+
]
|
|
617
|
+
},
|
|
618
|
+
{
|
|
619
|
+
"id": "text_injection",
|
|
620
|
+
"remediation_advice": "As a best practice, handle dynamic text input and use a whitelist of proper inputs."
|
|
621
|
+
},
|
|
622
|
+
{
|
|
623
|
+
"id": "homograph_idn_based",
|
|
624
|
+
"remediation_advice": "If disallowing URLs originating from user input is not an option, allow Unicode URLs only if all the characters belong to the same language that is chosen by user settings; display punycode URL otherwise. Some modern browsers will display these characters as punycode, e.g. spoofed `аррӏе.com` being `xn--80ak6aa92e.com`. However there are some best practices like use of an identity or password manager that can be recommended to users to help protect them against phishing.",
|
|
625
|
+
"references": [
|
|
626
|
+
"https://www.icann.org/news/announcement-2005-02-23-en",
|
|
627
|
+
"http://www.securityfocus.com/bid/12461",
|
|
628
|
+
"https://www.cvedetails.com/cve/CVE-2005-0238/"
|
|
629
|
+
]
|
|
630
|
+
},
|
|
631
|
+
{
|
|
632
|
+
"id": "rtlo",
|
|
633
|
+
"remediation_advice": "1. If possible avoid allowing Right to Left Override `\u202E` character in filenames and URLs.\n2. Avoid mixing right-to-left and left-to-right characters in a single name.",
|
|
634
|
+
"references": [
|
|
635
|
+
"https://dl.packetstormsecurity.net/papers/general/righttoleften-override.pdf"
|
|
636
|
+
]
|
|
637
|
+
}
|
|
638
|
+
]
|
|
639
|
+
}
|
|
640
|
+
]
|
|
641
|
+
},
|
|
642
|
+
{
|
|
643
|
+
"id": "broken_authentication_and_session_management",
|
|
644
|
+
"remediation_advice": "1. **API:** Use security focused APIs to check for proper security controls.\n2. **Session Management:** Use proper session management checks to disallow unauthenticated users accessing protected and sensitive resources.\n3. **Access Control:** Use proper access control checks to disallow unprivileged users from accessing protected and sensitive resources.",
|
|
645
|
+
"references": [
|
|
646
|
+
"https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication",
|
|
647
|
+
"https://www.owasp.org/index.php/Broken_Authentication_and_Session_Management",
|
|
648
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md",
|
|
649
|
+
"http://projects.webappsec.org/Insufficient-Authentication",
|
|
650
|
+
"https://www.cvedetails.com/vulnerability-list/opgpriv-1/gain-privilege.html"
|
|
651
|
+
],
|
|
652
|
+
"children": [
|
|
653
|
+
{
|
|
654
|
+
"id": "two_fa_bypass",
|
|
655
|
+
"references": [
|
|
656
|
+
"https://www.owasp.org/index.php/Testing_Multiple_Factors_Authentication_(OWASP-AT-009)"
|
|
657
|
+
]
|
|
658
|
+
},
|
|
659
|
+
{
|
|
660
|
+
"id": "cleartext_transmission_of_session_token",
|
|
661
|
+
"remediation_advice": "Ensure that session tokens are transmitted over protected channels at all times. If the secure cookie flag is not an option ensure that the application does not support unencrypted communication.",
|
|
662
|
+
"references": [
|
|
663
|
+
"https://www.owasp.org/index.php/Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003)",
|
|
664
|
+
"https://www.owasp.org/index.php/SecureFlag"
|
|
665
|
+
]
|
|
666
|
+
},
|
|
667
|
+
{
|
|
668
|
+
"id": "weak_login_function",
|
|
669
|
+
"remediation_advice": "Login forms should always be served over `HTTPS`, as well as all credentials should be transmitted over an encrypted channel at all times.\n\nAlways provide secure protocols for authentication connections as well as consider disabling any insecure protocols that are available.",
|
|
670
|
+
"references": [
|
|
671
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md#transmit-passwords-only-over-tls-or-other-strong-transport"
|
|
672
|
+
]
|
|
673
|
+
},
|
|
674
|
+
{
|
|
675
|
+
"id": "session_fixation",
|
|
676
|
+
"remediation_advice": "Always regenerate the session token after the users properly authenticate.",
|
|
677
|
+
"references": [
|
|
678
|
+
"http://projects.webappsec.org/w/page/13246960/Session%20Fixation"
|
|
679
|
+
]
|
|
680
|
+
},
|
|
681
|
+
{
|
|
682
|
+
"id": "failure_to_invalidate_session",
|
|
683
|
+
"children": [
|
|
684
|
+
{
|
|
685
|
+
"id": "on_logout",
|
|
686
|
+
"remediation_advice": "Properly invalidate the session on the client and server-side when the user logs out of their session.",
|
|
687
|
+
"references": [
|
|
688
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Session_Management_Cheat_Sheet.md#manual-session-expiration"
|
|
689
|
+
]
|
|
690
|
+
},
|
|
691
|
+
{
|
|
692
|
+
"id": "on_logout_server_side_only",
|
|
693
|
+
"remediation_advice": "Properly invalidate the session on the server-side when the user logs out of their session.",
|
|
694
|
+
"references": [
|
|
695
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Session_Management_Cheat_Sheet.md#manual-session-expiration"
|
|
696
|
+
]
|
|
697
|
+
},
|
|
698
|
+
{
|
|
699
|
+
"id": "on_password_change",
|
|
700
|
+
"remediation_advice": "Properly invalidate all user sessions server-side when the user resets their password and at a minimum, invalidate all non-current user sessions sever-side when the user changes their password.",
|
|
701
|
+
"references": [
|
|
702
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Session_Management_Cheat_Sheet.md#renew-the-session-id-after-any-privilege-level-change"
|
|
703
|
+
]
|
|
704
|
+
},
|
|
705
|
+
{
|
|
706
|
+
"id": "all_sessions",
|
|
707
|
+
"remediation_advice": "As a best practice, consider invalidating all user sessions on logout."
|
|
708
|
+
},
|
|
709
|
+
{
|
|
710
|
+
"id": "on_email_change",
|
|
711
|
+
"remediation_advice": "As a best practice, consider invalidating all sessions upon email change."
|
|
712
|
+
},
|
|
713
|
+
{
|
|
714
|
+
"id": "on_two_fa_activation_change",
|
|
715
|
+
"remediation_advice": "As a best practice, consider invalidating all sessions upon 2FA activation or change."
|
|
716
|
+
},
|
|
717
|
+
{
|
|
718
|
+
"id": "long_timeout",
|
|
719
|
+
"remediation_advice": "As a best practice, consider invalidating sessions after a shorter period of time."
|
|
720
|
+
}
|
|
721
|
+
]
|
|
722
|
+
},
|
|
723
|
+
{
|
|
724
|
+
"id": "concurrent_logins",
|
|
725
|
+
"remediation_advice": "As a best practice, consider disallowing multiple concurrent user sessions or logins."
|
|
726
|
+
}
|
|
727
|
+
]
|
|
728
|
+
},
|
|
729
|
+
{
|
|
730
|
+
"id": "sensitive_data_exposure",
|
|
731
|
+
"remediation_advice": "Do the following, at a minimum, and consult the references:\n\n1. Classify data processed, stored or transmitted by an application. Identify which data is sensitive according to privacy laws, regulatory requirements, or business needs.\n2. Apply controls as per the classification.\n3. Don't store sensitive data unnecessarily. Discard it as soon as possible or use PCI DSS compliant tokenization or even truncation. Data that is not retained cannot be stolen.\n4. Make sure to encrypt all sensitive data at rest.\n5. Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use proper key management.\n6. Encrypt all data in transit with secure protocols such as TLS with perfect forward secrecy (PFS) ciphers, cipher prioritization by the server, and secure parameters. Enforce encryption using directives like `HTTP Strict Transport Security` (HSTS).\n7. Disable caching for response that contain sensitive data.\n8. Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as `Argon2`, `scrypt`, `bcrypt` or `PBKDF2`.\n9. Verify independently the effectiveness of configuration and settings.",
|
|
732
|
+
"references": [
|
|
733
|
+
"https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure",
|
|
734
|
+
"http://projects.webappsec.org/Information-Leakage",
|
|
735
|
+
"https://blog.detectify.com/2016/07/01/owasp-top-10-sensitive-data-exposure-6/",
|
|
736
|
+
"https://www.cvedetails.com/vulnerability-list/opginf-1/gain-information.html"
|
|
737
|
+
],
|
|
738
|
+
"children": [
|
|
739
|
+
{
|
|
740
|
+
"id": "critically_sensitive_data",
|
|
741
|
+
"children": [
|
|
742
|
+
{
|
|
743
|
+
"id": "private_api_keys",
|
|
744
|
+
"remediation_advice": "1. Do not store private API keys in source code that is publicly accessible such as in a public GitHub repository.\n2. Critically sensitive data should not be sent over cleartext. Make sure to only use `HTTPS` whenever transmitting private API keys.\n3. Browser headers are set to not cache when the sensitive data is presented to end-user."
|
|
745
|
+
}
|
|
746
|
+
]
|
|
747
|
+
},
|
|
748
|
+
{
|
|
749
|
+
"id": "exif_geolocation_data_not_stripped_from_uploaded_images",
|
|
750
|
+
"remediation_advice": "Remove all sensitive data from `EXIF` geolocation data from images after being uploaded to the server to prevent sensitive data exposure.",
|
|
751
|
+
"references": [
|
|
752
|
+
"http://resources.infosecinstitute.com/metadata-and-information-security/"
|
|
753
|
+
]
|
|
754
|
+
},
|
|
755
|
+
{
|
|
756
|
+
"id": "visible_detailed_error_page",
|
|
757
|
+
"remediation_advice": "Turn off visible detailed error pages on production servers. Replace detailed error messages with generic error messages. This will be unuseful to attackers trying to get more reconnaissance information about the application or the server.",
|
|
758
|
+
"references": [
|
|
759
|
+
"https://www.owasp.org/index.php/Improper_Error_Handling"
|
|
760
|
+
]
|
|
761
|
+
},
|
|
762
|
+
{
|
|
763
|
+
"id": "disclosure_of_known_public_information",
|
|
764
|
+
"remediation_advice": "As a best practice, avoid disclosing known public information unnecessarily."
|
|
765
|
+
},
|
|
766
|
+
{
|
|
767
|
+
"id": "token_leakage_via_referer",
|
|
768
|
+
"remediation_advice": "Do not expose a sensitive token through insecure requests, as to not send the token in the `Referer` header, over cleartext HTTP or when going off-site to a 3rd party."
|
|
769
|
+
},
|
|
770
|
+
{
|
|
771
|
+
"id": "sensitive_token_in_url",
|
|
772
|
+
"remediation_advice": "Avoid putting any sensitive token in the URLs. The token can be found in cleartext wherever the URL is stored (eg: within unencrypted log files or browser cache). Instead, sensitive tokens should be sent in the HTTPS headers. Ensure all sensitive data is only transmitted via `HTTPS`."
|
|
773
|
+
},
|
|
774
|
+
{
|
|
775
|
+
"id": "non_sensitive_token_in_url",
|
|
776
|
+
"remediation_advice": "Avoid putting tokens in the URLs. The token can be found in cleartext wherever the URL is stored (eg: within unencrypted log files or browser cache). Instead, tokens should be sent in the HTTPS headers. Ensure all sensitive data is only transmitted via `HTTPS`."
|
|
777
|
+
},
|
|
778
|
+
{
|
|
779
|
+
"id": "weak_password_reset_implementation",
|
|
780
|
+
"references": [
|
|
781
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Forgot_Password_Cheat_Sheet.md",
|
|
782
|
+
"http://projects.webappsec.org/Insufficient-Password-Recovery"
|
|
783
|
+
],
|
|
784
|
+
"children": [
|
|
785
|
+
{
|
|
786
|
+
"id": "password_reset_token_sent_over_http",
|
|
787
|
+
"remediation_advice": "Avoid sending a password reset token over `HTTP`. A password reset token must always be transmitted via `HTTPS`."
|
|
788
|
+
},
|
|
789
|
+
{
|
|
790
|
+
"id": "token_leakage_via_host_header_poisoning",
|
|
791
|
+
"remediation_advice": "If the web application makes use of the host header value when composing the reset link, an attacker can poison the password reset link that is sent to a victim. If the victim clicks on the poisoned reset link in the email, the attacker will obtain the password reset token and can go ahead and reset the victim’s password. To protect your systems from this type of attack never trust the host header as it is controlled by the users.",
|
|
792
|
+
"references": [
|
|
793
|
+
"https://www.acunetix.com/blog/articles/automated-detection-of-host-header-attacks/"
|
|
794
|
+
]
|
|
795
|
+
}
|
|
796
|
+
]
|
|
797
|
+
},
|
|
798
|
+
{
|
|
799
|
+
"id": "mixed_content",
|
|
800
|
+
"remediation_advice": "To protect all elements of a page from sniffers and man-in-the-middle attacks, ensure that all content such as scripts, images, iframes, etc, are sourced over HTTPS rather than HTTP.",
|
|
801
|
+
"references": [
|
|
802
|
+
"https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Do_Not_Mix_TLS_and_Non-TLS_Content",
|
|
803
|
+
"https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content"
|
|
804
|
+
]
|
|
805
|
+
},
|
|
806
|
+
{
|
|
807
|
+
"id": "sensitive_data_hardcoded",
|
|
808
|
+
"children": [
|
|
809
|
+
{
|
|
810
|
+
"id": "oauth_secret",
|
|
811
|
+
"remediation_advice": "Consider using OAuth Implicit Grant to avoid hardcoding the OAuth secret key within the application.",
|
|
812
|
+
"references": [
|
|
813
|
+
"https://tools.ietf.org/html/rfc6749#section-4.2"
|
|
814
|
+
]
|
|
815
|
+
}
|
|
816
|
+
]
|
|
817
|
+
},
|
|
818
|
+
{
|
|
819
|
+
"id": "xssi",
|
|
820
|
+
"remediation_advice": "1. Avoid placing sensitive content inside JavaScript files, and also not in `JSONP`.\n2. Consider using a CSRF token.\n3. Sensitive scripts should only respond to POST requests.\n4. Append some non-executable prefix to the response body.\n5. Usage of the response header `X-Content-Type-Options: nosniff` and usage of the correct `Content-Type` is also helpful in reducing the chance of XSSI.",
|
|
821
|
+
"references": [
|
|
822
|
+
"https://www.scip.ch/en/?labs.20160414"
|
|
823
|
+
]
|
|
824
|
+
},
|
|
825
|
+
{
|
|
826
|
+
"id": "json_hijacking",
|
|
827
|
+
"remediation_advice": "Follow the JSON specification which requires an object as top level entity. If the top level object is an array, the response will be a valid Java Script code that might be parsed using a `<script>` tag.",
|
|
828
|
+
"references": [
|
|
829
|
+
"http://www.thespanner.co.uk/2011/05/30/json-hijacking/"
|
|
830
|
+
]
|
|
831
|
+
}
|
|
832
|
+
]
|
|
833
|
+
},
|
|
834
|
+
{
|
|
835
|
+
"id": "cross_site_scripting_xss",
|
|
836
|
+
"remediation_advice": "1. Always treat all user input as untrusted data.\n2. Never insert untrusted data except in allowed locations.\n3. Always input or output-encode all data coming into or out of the application.\n4. Always whitelist allowed characters and seldom use blacklisting of characters except in certain use cases.\n5. Always use a well-known and security encoding API for input and output encoding such as the `OWASP ESAPI`.\n6. Never try to write input and output encoders unless absolutely necessary. Chances are that someone has already written a good one.\n7. Never use the DOM function `innerHtml` and instead use the functions `innerText` and `textContent` to prevent against DOM-based XSS.\n8. As a best practice, consider using the `HTTPOnly` flag on cookies that are session tokens or sensitive tokens.\n9. As a best practice, consider implementing `Content Security Policy` to protect against XSS and other injection type attacks.\n10. As a best practice, consider using an auto-escaping templating system.\n11. As a best practice, consider using the `X-XSS-Protection` response header.",
|
|
837
|
+
"references": [
|
|
838
|
+
"https://www.owasp.org/index.php/Top_10-2017_A7-Cross-Site_Scripting_(XSS)",
|
|
839
|
+
"https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)",
|
|
840
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md",
|
|
841
|
+
"http://projects.webappsec.org/Cross-Site+Scripting",
|
|
842
|
+
"https://www.cvedetails.com/vulnerability-list/opxss-1/xss.html"
|
|
843
|
+
],
|
|
844
|
+
"children": [
|
|
845
|
+
{
|
|
846
|
+
"id": "ie_only",
|
|
847
|
+
"children": [
|
|
848
|
+
{
|
|
849
|
+
"id": "xss_filter_disabled",
|
|
850
|
+
"remediation_advice": "As a best practice do not disable the XSS filter by utilizing `X-XSS-Protection: 0` header.",
|
|
851
|
+
"references": [
|
|
852
|
+
"https://msdn.microsoft.com/en-us/library/dd565647(v=vs.85).aspx"
|
|
853
|
+
]
|
|
854
|
+
}
|
|
855
|
+
]
|
|
856
|
+
},
|
|
857
|
+
{
|
|
858
|
+
"id": "trace_method",
|
|
859
|
+
"remediation_advice": "As the TRACE method can be utilized to bypass certain protections, consider disabling the HTTP method TRACE.",
|
|
860
|
+
"references": [
|
|
861
|
+
"https://www.owasp.org/index.php/Cross_Site_Tracing"
|
|
862
|
+
]
|
|
863
|
+
}
|
|
864
|
+
]
|
|
865
|
+
},
|
|
866
|
+
{
|
|
867
|
+
"id": "broken_access_control",
|
|
868
|
+
"children": [
|
|
869
|
+
{
|
|
870
|
+
"id": "idor",
|
|
871
|
+
"remediation_advice": "1. **Use per user or session indirect object references.** This prevents attackers from directly targeting unauthorized resources. For example, instead of using the resource's database key, a drop-down list of six resources authorized for the current user could use the numbers 1 to 6 to indicate which value the user selected. The application has to map the per-user indirect reference back to the actual database key on the server. OWASP's `ESAPI` includes both sequential and random access reference maps that developers can use to eliminate direct object references.\n2. **Check access.** Each use of a direct object reference from an untrusted source must include an access control check to ensure the user is authorized for the requested object.",
|
|
872
|
+
"references": [
|
|
873
|
+
"https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References",
|
|
874
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.md"
|
|
875
|
+
]
|
|
876
|
+
},
|
|
877
|
+
{
|
|
878
|
+
"id": "server_side_request_forgery_ssrf",
|
|
879
|
+
"remediation_advice": "1. **Error handling and messages:** Display generic error messages to the client in case something goes wrong. If content type validation fails, display generic errors to the client like _“Invalid Data retrieved”_. Also ensure that the message is the same when the request fails on the backend and if invalid data is received. This will prevent the application from being abused as distinct error messages will be absent for closed and open ports. Under no circumstance should the raw response received from the remote server be displayed to the client.\n2. **Response Handling:** Validating responses received from remote resources on the server side is the most basic mitigation that can be readily implemented. If a web application expects specific content type on the server, programmatically ensure that the data received satisfies checks imposed on the server before displaying or processing the data for the client.\n3. **Disable unwanted protocols:** Allow only `http` and `https` to make requests to remote servers. Whitelisting these protocols will prevent the web application from making requests over other protocols like `file:///`, `gopher://`, `ftp://` and other URI schemes.\n4. **Blacklist IP addresses:** Internal IP addresses, localhost specifications and internal hostnames can all be blacklisted to prevent the web application from being abused to fetch data/attack these devices. Implementing this will protect servers from one time attack vectors. For example, even if the first fix (above) is implemented, the data is still being sent to the remote service. If an attack that does not need to see responses is executed (like a buffer overflow exploit) then this fix can actually prevent data from ever reaching the vulnerable device. Response handling is then not required at all as a request was never made.",
|
|
880
|
+
"references": [
|
|
881
|
+
"https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control",
|
|
882
|
+
"http://projects.webappsec.org/w/page/13246913/Abuse%20of%20Functionality",
|
|
883
|
+
"http://resources.infosecinstitute.com/the-ssrf-vulnerability/",
|
|
884
|
+
"https://www.bishopfox.com/blog/2015/04/vulnerable-by-design-understanding-server-side-request-forgery/",
|
|
885
|
+
"http://niiconsulting.com/checkmate/2015/04/server-side-request-forgery-ssrf/"
|
|
886
|
+
]
|
|
887
|
+
},
|
|
888
|
+
{
|
|
889
|
+
"id": "username_enumeration",
|
|
890
|
+
"remediation_advice": "Ensure that the application does not reveal existing user names and any data associated with them, whether it's a consequence of misconfiguration or a design decision.",
|
|
891
|
+
"references": [
|
|
892
|
+
"https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control",
|
|
893
|
+
"https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure",
|
|
894
|
+
"http://projects.webappsec.org/w/page/13246936/Information%20Leakage"
|
|
895
|
+
]
|
|
896
|
+
},
|
|
897
|
+
{
|
|
898
|
+
"id": "exposed_sensitive_android_intent",
|
|
899
|
+
"remediation_advice": "1. If you use an intent to bind to a Service, ensure that your app is secure by using an explicit intent. Using an implicit intent to start a service is a security risk as you can't be certain what service will respond to the intent, and the user can't see which service starts.\n2. If data within a broadcast intent may be sensitive, you should consider applying a permission to make sure that malicious applications can't register to receive those messages without appropriate permissions. In these circumstances you may also consider invoking the receiver directly rather than raising a broadcast.\n3. By default, receivers are exported and can be invoked by any other application. If your BroadcastReceiver is intended for use by other applications, you may want to apply security permissions to receivers using the <receiver> element within the application manifest. This prevents applications without appropriate permissions from sending an intent to the BroadcastReceiver.\n",
|
|
900
|
+
"references": [
|
|
901
|
+
"https://www.owasp.org/index.php/Mobile_Top_10_2016-M1-Improper_Platform_Usage"
|
|
902
|
+
]
|
|
903
|
+
},
|
|
904
|
+
{
|
|
905
|
+
"id": "exposed_sensitive_ios_url_scheme",
|
|
906
|
+
"remediation_advice": "Apple does not enforce the unique naming for App schemes, making it possible for a malicious app to use the same URL Scheme as a legitimate app, effectively hijacking the URL Scheme. As a result, it is important to keep the URL Scheme from being exposed.",
|
|
907
|
+
"references": [
|
|
908
|
+
"https://www.owasp.org/index.php/Mobile_Top_10_2016-M1-Improper_Platform_Usage",
|
|
909
|
+
"https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html"
|
|
910
|
+
]
|
|
911
|
+
}
|
|
912
|
+
]
|
|
913
|
+
},
|
|
914
|
+
{
|
|
915
|
+
"id": "cross_site_request_forgery_csrf",
|
|
916
|
+
"remediation_advice": "1. Consider using a known and secure CSRF synchronizer API and apply the generated CSRF token to every request. If infeasible to apply to every request, generate a CSRF token for the entire session and apply that to every request or, at minimum, every request considered sensitive. Always make sure to check the actual CSRF token.\n2. Consider verifying using same-origin rules to the source and target by checking the `Origin` and `Referer` headers.\n3. Consider using the `Double Submit Cookie` pattern.\n4. Consider using the `Encrypted Token` pattern.\n5. Consider protecting REST services by using the `X-Requested-With: XMLHttpRequest` header in all requests.\n6. Consider using re-authentication in cases where the request is particularly sensitive. This is the most effective CSRF prevention technique, however it does disturb the entire user experience.",
|
|
917
|
+
"references": [
|
|
918
|
+
"https://www.owasp.org/index.php/Top_10_2013-A8-Cross-Site_Request_Forgery_(CSRF)",
|
|
919
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md",
|
|
920
|
+
"http://projects.webappsec.org/w/page/13246919/Cross%20Site%20Request%20Forgery",
|
|
921
|
+
"https://www.cvedetails.com/vulnerability-list/opcsrf-1/csrf.html"
|
|
922
|
+
]
|
|
923
|
+
},
|
|
924
|
+
{
|
|
925
|
+
"id": "application_level_denial_of_service_dos",
|
|
926
|
+
"remediation_advice": "There are techniques to avoid some DoS attacks at the code level such as: Performing thorough input validations, avoiding highly CPU consuming operations, and operations which must wait for completion of large tasks to proceed, splitting operations to chunks, setting timeout timers for unreasonable time, trying to create as few bottlenecks as possible.",
|
|
927
|
+
"references": [
|
|
928
|
+
"https://www.owasp.org/index.php/Application_Denial_of_Service",
|
|
929
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Denial_of_Service_Cheat_Sheet.md",
|
|
930
|
+
"http://projects.webappsec.org/Denial-of-Service",
|
|
931
|
+
"https://www.cvedetails.com/vulnerability-list/opdos-1/denial-of-service.html",
|
|
932
|
+
"https://www.owasp.org/images/d/da/OWASP_IL_7_Application_DOS.pdf"
|
|
933
|
+
]
|
|
934
|
+
},
|
|
935
|
+
{
|
|
936
|
+
"id": "unvalidated_redirects_and_forwards",
|
|
937
|
+
"remediation_advice": "1. Avoid using redirects or forwards and only use them in specific use cases.\n2. Use input validation to check the origin of the URL in the parameter being passed. If the URL is not the same origin as the current domain, do not redirect off-domain.\n3. If the redirection is part of intended functionality, alert the user that they are going off-domain and let them make the decision to go off-domain. Present the redirection URL to the user to make it clear they are going off-domain.\n4. Whitelist valid domains that users should be allowed to be redirected to.",
|
|
938
|
+
"references": [
|
|
939
|
+
"https://www.owasp.org/index.php/Top_10_2013-A10-Unvalidated_Redirects_and_Forwards",
|
|
940
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.md",
|
|
941
|
+
"http://projects.webappsec.org/w/page/13246981/URL%20Redirector%20Abuse"
|
|
942
|
+
],
|
|
943
|
+
"children": [
|
|
944
|
+
{
|
|
945
|
+
"id": "tabnabbing",
|
|
946
|
+
"remediation_advice": "There are a handful of solutions, however they might not be supported by all browsers:\n\n1. Remove or disallow target=\"_blank\" for any anchors pointing to a different origin.\n2. Append rel=\"noreferrer\" to any links with target=\"_blank\", but keep in mind that it prevents sending `Referer` in the request headers.\n3. Append rel=\"noopener\" to any links with target=\"_blank\".\n4. Install a tabnabbing prevention script.",
|
|
947
|
+
"references": [
|
|
948
|
+
"http://www.azarask.in/blog/post/a-new-type-of-phishing-attack/"
|
|
949
|
+
]
|
|
950
|
+
},
|
|
951
|
+
{
|
|
952
|
+
"id": "lack_of_security_speed_bump_page",
|
|
953
|
+
"remediation_advice": "As a best practice, consider adding a page to alert the user that they are going off-domain and let them make the decision to go off-domain. Present the redirection URL to the user to make it clear they are going off-domain."
|
|
954
|
+
}
|
|
955
|
+
]
|
|
956
|
+
},
|
|
957
|
+
{
|
|
958
|
+
"id": "external_behavior",
|
|
959
|
+
"remediation_advice": "Whenever possible ensure that any security controls that help affect external appliations are in place.",
|
|
960
|
+
"children": [
|
|
961
|
+
{
|
|
962
|
+
"id": "browser_feature",
|
|
963
|
+
"children": [
|
|
964
|
+
{
|
|
965
|
+
"id": "plaintext_password_field",
|
|
966
|
+
"remediation_advice": "As a best practice, do not allow password fields to be shown in plain text instead of masked."
|
|
967
|
+
},
|
|
968
|
+
{
|
|
969
|
+
"id": "save_password",
|
|
970
|
+
"remediation_advice": "As a best practice, do not use \"remember me\" functionality to enable users to save their passwords. Attackers find an attack vector to access the browser's built in password manager and steal the credentials of the user."
|
|
971
|
+
},
|
|
972
|
+
{
|
|
973
|
+
"id": "autocomplete_enabled",
|
|
974
|
+
"remediation_advice": "As a best practice, do not have Autocomplete enabled by default."
|
|
975
|
+
},
|
|
976
|
+
{
|
|
977
|
+
"id": "autocorrect_enabled",
|
|
978
|
+
"remediation_advice": "Should the autocorrect feature cause unintended issues, disable autocorrect."
|
|
979
|
+
},
|
|
980
|
+
{
|
|
981
|
+
"id": "aggressive_offline_caching",
|
|
982
|
+
"remediation_advice": "Avoid caching data unnecessarily, especially sensitive information."
|
|
983
|
+
}
|
|
984
|
+
]
|
|
985
|
+
}
|
|
986
|
+
]
|
|
987
|
+
},
|
|
988
|
+
{
|
|
989
|
+
"id": "insufficient_security_configurability",
|
|
990
|
+
"references": [
|
|
991
|
+
"https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration"
|
|
992
|
+
],
|
|
993
|
+
"children": [
|
|
994
|
+
{
|
|
995
|
+
"id": "weak_password_policy",
|
|
996
|
+
"remediation_advice": "1. Allow all characters to be used for passwords to avoid shortening the key space for brute-force guessing.\n2. Do not impose character restrictions such as \"must have at least X number of specific character type\" in the password. This will shorten the key space for brute-force guessing.\n2. Disallow short password lengths. 8 characters is generally considered a good minimum password length.\n3. Allow for a large maximum password length.\n4. Do not advertise the maximum password length as this will shorten the key space for brute-force guessing.\n5. Disallow previous passwords from being used.\n6. Disallow the password being the same as the email or username.",
|
|
997
|
+
"references": [
|
|
998
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md#implement-proper-password-strength-controls"
|
|
999
|
+
]
|
|
1000
|
+
},
|
|
1001
|
+
{
|
|
1002
|
+
"id": "no_password_policy",
|
|
1003
|
+
"remediation_advice": "1. Allow all characters to be used for passwords to avoid shortening the key space for brute-force guessing.\n2. Do not impose character restrictions such as \"must have at least X number of specific character type\" in the password. This will shorten the key space for brute-force guessing.\n2. Disallow short password lengths. 8 characters is generally considered a good minimum password length.\n3. Allow for a large maximum password length.\n4. Do not advertise the maximum password length as this will shorten the key space for brute-force guessing.\n5. Disallow previous passwords from being used.\n6. Disallow the password being the same as the email or username.",
|
|
1004
|
+
"references": [
|
|
1005
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md#implement-proper-password-strength-controls"
|
|
1006
|
+
]
|
|
1007
|
+
},
|
|
1008
|
+
{
|
|
1009
|
+
"id": "weak_password_reset_implementation",
|
|
1010
|
+
"references": [
|
|
1011
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Forgot_Password_Cheat_Sheet.md#step-3-send-a-token-over-a-side-channel",
|
|
1012
|
+
"http://projects.webappsec.org/w/page/13246942/Insufficient%20Password%20Recovery"
|
|
1013
|
+
],
|
|
1014
|
+
"children": [
|
|
1015
|
+
{
|
|
1016
|
+
"id": "token_is_not_invalidated_after_use",
|
|
1017
|
+
"remediation_advice": "The password reset token should be invalidated immediately after it is used."
|
|
1018
|
+
},
|
|
1019
|
+
{
|
|
1020
|
+
"id": "token_is_not_invalidated_after_email_change",
|
|
1021
|
+
"remediation_advice": "If the email address is changed and there is an active password reset token, the token should be invalidated."
|
|
1022
|
+
},
|
|
1023
|
+
{
|
|
1024
|
+
"id": "token_is_not_invalidated_after_password_change",
|
|
1025
|
+
"remediation_advice": "All existing password reset tokens should be invalidated once the password has been successfully changed."
|
|
1026
|
+
},
|
|
1027
|
+
{
|
|
1028
|
+
"id": "token_has_long_timed_expiry",
|
|
1029
|
+
"remediation_advice": "The password reset token should expire after a limited amount of time. Six hours should be a sufficient expiration time limit."
|
|
1030
|
+
},
|
|
1031
|
+
{
|
|
1032
|
+
"id": "token_is_not_invalidated_after_new_token_is_requested",
|
|
1033
|
+
"remediation_advice": "When a new password reset token is issued, all previous tokens should be invalidated and only the newest token should be active."
|
|
1034
|
+
},
|
|
1035
|
+
{
|
|
1036
|
+
"id": "token_is_not_invalidated_after_login",
|
|
1037
|
+
"remediation_advice": "When the user successfully authenticates, any unused password reset token should be invalidated."
|
|
1038
|
+
}
|
|
1039
|
+
]
|
|
1040
|
+
},
|
|
1041
|
+
{
|
|
1042
|
+
"id": "lack_of_verification_email",
|
|
1043
|
+
"remediation_advice": "As a best practice, consider sending a verification email when a change is made, such as changing the account password or email."
|
|
1044
|
+
},
|
|
1045
|
+
{
|
|
1046
|
+
"id": "lack_of_notification_email",
|
|
1047
|
+
"remediation_advice": "As a best practice, consider sending a notification email when questionable activity occurs, such as multiple unsuccessful login attempts."
|
|
1048
|
+
},
|
|
1049
|
+
{
|
|
1050
|
+
"id": "weak_registration_implementation",
|
|
1051
|
+
"children": [
|
|
1052
|
+
{
|
|
1053
|
+
"id": "allows_disposable_email_addresses",
|
|
1054
|
+
"remediation_advice": "As a best practice, consider disallowing registrations utilizing known disposable email addresses."
|
|
1055
|
+
}
|
|
1056
|
+
]
|
|
1057
|
+
},
|
|
1058
|
+
{
|
|
1059
|
+
"id": "weak_two_fa_implementation",
|
|
1060
|
+
"remediation_advice": "Ensure that the second factor authentication is properly configured and cannot be bypassed. 2FA secret should be rotated every time 2FA is reenabled by the user and not remain obtainable after 2FA is turned on. Additionally consider providing a 2FA failsafe mechanism so the users can safely recover their accounts."
|
|
1061
|
+
}
|
|
1062
|
+
]
|
|
1063
|
+
},
|
|
1064
|
+
{
|
|
1065
|
+
"id": "using_components_with_known_vulnerabilities",
|
|
1066
|
+
"references": [
|
|
1067
|
+
"https://www.owasp.org/index.php/Top_10-2017_A9-Using_Components_with_Known_Vulnerabilities"
|
|
1068
|
+
],
|
|
1069
|
+
"children": [
|
|
1070
|
+
{
|
|
1071
|
+
"id": "rosetta_flash",
|
|
1072
|
+
"remediation_advice": "Since Flash files cannot start with comments, ensuring that `callback` parameters begin with a comment, such as: `/* */` is a sufficient protection.",
|
|
1073
|
+
"references": [
|
|
1074
|
+
"https://blog.avira.com/understanding-rosetta-flash-vulnerability/",
|
|
1075
|
+
"https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4671"
|
|
1076
|
+
]
|
|
1077
|
+
},
|
|
1078
|
+
{
|
|
1079
|
+
"id": "outdated_software_version",
|
|
1080
|
+
"remediation_advice": "As a best practice, keep all software up to date, especially if there exists a known vulnerability or weakness associated with an older version."
|
|
1081
|
+
},
|
|
1082
|
+
{
|
|
1083
|
+
"id": "captcha_bypass",
|
|
1084
|
+
"children": [
|
|
1085
|
+
{
|
|
1086
|
+
"id": "ocr_optical_character_recognition",
|
|
1087
|
+
"remediation_advice": "As a best practice, consider using a CAPTCHA that is not known to be bypassable using automation, such as those that are easily recognizable by a machine."
|
|
1088
|
+
}
|
|
1089
|
+
]
|
|
1090
|
+
}
|
|
1091
|
+
]
|
|
1092
|
+
},
|
|
1093
|
+
{
|
|
1094
|
+
"id": "insecure_data_storage",
|
|
1095
|
+
"remediation_advice": "Consider encrypting data for storage, using the strongest encryption algorithms such as AES with a minimum of a 256-bit key size.",
|
|
1096
|
+
"references": [
|
|
1097
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cryptographic_Storage_Cheat_Sheet.md",
|
|
1098
|
+
"https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure"
|
|
1099
|
+
],
|
|
1100
|
+
"children": [
|
|
1101
|
+
{
|
|
1102
|
+
"id": "sensitive_application_data_stored_unencrypted",
|
|
1103
|
+
"children": [
|
|
1104
|
+
{
|
|
1105
|
+
"id": "on_external_storage",
|
|
1106
|
+
"remediation_advice": "1. Never store sensitive application data unencrypted.\n2. Use the strongest encryption algorithms such as AES with a minimum of a 256-bit key size for application data storage."
|
|
1107
|
+
}
|
|
1108
|
+
]
|
|
1109
|
+
},
|
|
1110
|
+
{
|
|
1111
|
+
"id": "server_side_credentials_storage",
|
|
1112
|
+
"remediation_advice": "1. Never try to create your own cryptographic functions.\n2. Always use well-known, strong, and secure cryptographic API functions.\n3. Never store cleartext password strings anywhere.\n4. Always salt password strings before running through a cryptographically safe hashing algorithm.\n5. Always use a random salt for each password string.\n6. Always store the salt and the cryptographically hashed password string in an encrypted database.\n7. Never use unsafe hashing functions such as `MD5` or `SHA1` which have low key spaces and have working proofs of concept that break these hashing functions.\n8. Only use cryptographically safe hashing functions such as `SHA-256` and above.\n9. Never use unsafe encryption functions that have working proofs of concept that prove that they are broken.\n10. Only use cryptographically safe encryption functions that have a very high work factor to discourage attackers from trying to break the encryption, such as `bcrypt`, `scrypt`, and `PBKDF2`."
|
|
1113
|
+
},
|
|
1114
|
+
{
|
|
1115
|
+
"id": "screen_caching_enabled",
|
|
1116
|
+
"remediation_advice": "As a best practice, consider preventing background screen caching if the application displays sensitive data."
|
|
1117
|
+
}
|
|
1118
|
+
]
|
|
1119
|
+
},
|
|
1120
|
+
{
|
|
1121
|
+
"id": "lack_of_binary_hardening",
|
|
1122
|
+
"remediation_advice": "To ensure security throughout the life cycle of an application, it is a good practice to harden binaries with memory protections, and significantly increase the cost of reverse engineering and code modification.",
|
|
1123
|
+
"references": [
|
|
1124
|
+
"https://wiki.debian.org/Hardening",
|
|
1125
|
+
"https://www.owasp.org/index.php/Mobile_Top_10_2014-M10"
|
|
1126
|
+
]
|
|
1127
|
+
},
|
|
1128
|
+
{
|
|
1129
|
+
"id": "insecure_data_transport",
|
|
1130
|
+
"remediation_advice": "1. Require `TLS` for all sensitive pages. Non-`TLS` requests to these pages should be redirected to the `TLS` page.\n2. Set the `Secure` flag on all sensitive cookies.\n3. Configure your `TLS` provider to only support strong (e.g., `FIPS 140-2` compliant) algorithms.\n4. Ensure your certificate is valid, not expired, not revoked, and matches all domains used by the site.\n5. Backend and other connections should also use `TLS` or other encryption technologies.",
|
|
1131
|
+
"references": [
|
|
1132
|
+
"https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection"
|
|
1133
|
+
]
|
|
1134
|
+
},
|
|
1135
|
+
{
|
|
1136
|
+
"id": "insecure_os_firmware",
|
|
1137
|
+
"children": [
|
|
1138
|
+
{
|
|
1139
|
+
"id": "command_injection",
|
|
1140
|
+
"remediation_advice": "1. Avoid using shell execution functions. If unavoidable, limit their use to very specific use cases.\n2. Perform proper input validation when taking user input into a shell execution command.\n3. Use a safe API when accepting user input into the application.\n4. Escape special characters in the case where a safe API is not available.",
|
|
1141
|
+
"references": [
|
|
1142
|
+
"https://www.owasp.org/index.php/Top_10-2017_A1-Injection",
|
|
1143
|
+
"https://www.owasp.org/index.php/Command_Injection",
|
|
1144
|
+
"http://projects.webappsec.org/OS-Commanding",
|
|
1145
|
+
"https://www.owasp.org/index.php/Injection_Prevention_Cheat_Sheet",
|
|
1146
|
+
"https://www.cvedetails.com/vulnerability-list/opec-1/execute-code.html"
|
|
1147
|
+
]
|
|
1148
|
+
},
|
|
1149
|
+
{
|
|
1150
|
+
"id": "hardcoded_password",
|
|
1151
|
+
"remediation_advice": "1. Never use a hardcoded password within the source code. Many times, the application can be disassembled or decompiled after it has been compiled. This will likely reveal the hardcoded password string to an attacker.\n2. Never use a password string. Instead, use a random salt per user with the password string and run it through a cryptographically strong hashing algorithm.\n3. Store the salt and the hashed password server-side and do the check there. Never check the password on the client side.",
|
|
1152
|
+
"references": [
|
|
1153
|
+
"https://www.owasp.org/index.php/Password_Management:_Hardcoded_Password",
|
|
1154
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Password_Storage_Cheat_Sheet.md"
|
|
1155
|
+
]
|
|
1156
|
+
}
|
|
1157
|
+
]
|
|
1158
|
+
},
|
|
1159
|
+
{
|
|
1160
|
+
"id": "broken_cryptography",
|
|
1161
|
+
"children": [
|
|
1162
|
+
{
|
|
1163
|
+
"id": "cryptographic_flaw",
|
|
1164
|
+
"children": [
|
|
1165
|
+
{
|
|
1166
|
+
"id": "incorrect_usage",
|
|
1167
|
+
"remediation_advice": "1. Never try to create your own cryptographic functions.\n2. Always use known, strong, and secure cryptographic API functions.\n3. Never store cleartext password strings anywhere.\n4. Always salt password strings before running through a cryptographically safe hashing algorithms.\n5. Always use a random salt for each password string.\n6. Always store the salt and the cryptographically hashed password string in an encrypted database.\n7. Never use unsafe hashing functions such as `MD5` and `SHA1` which have low key spaces and have working proof of concepts that break these hashing functions.\n8. Only use cryptographically safe hashing functions such as `SHA-256` and above.\n9. Never use unsafe encryption functions that have working proof of concepts that prove that they are broken.\n10. Only use cryptographically safe encryption functions that have a very high work factor to discourage attackers from trying to break the encryption such as `bcrypt`, `scrypt`, and `PBKDF2`.",
|
|
1168
|
+
"references": [
|
|
1169
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cryptographic_Storage_Cheat_Sheet.md",
|
|
1170
|
+
"https://crackstation.net/hashing-security.htm"
|
|
1171
|
+
]
|
|
1172
|
+
}
|
|
1173
|
+
]
|
|
1174
|
+
}
|
|
1175
|
+
]
|
|
1176
|
+
},
|
|
1177
|
+
{
|
|
1178
|
+
"id": "privacy_concerns",
|
|
1179
|
+
"remediation_advice": "1. Avoid storing unnecessary data where possible.\n2. Purge all known unnecessary data when identified on the device or application.\n3. Purge all known unnecessary data in known cached locations.\n4. Purge all known unnecessary data on known backup locations.",
|
|
1180
|
+
"references": [
|
|
1181
|
+
"https://www.owasp.org/index.php/Privacy_Violation",
|
|
1182
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/User_Privacy_Protection_Cheat_Sheet.md"
|
|
1183
|
+
]
|
|
1184
|
+
},
|
|
1185
|
+
{
|
|
1186
|
+
"id": "network_security_misconfiguration",
|
|
1187
|
+
"children": [
|
|
1188
|
+
{
|
|
1189
|
+
"id": "telnet_enabled",
|
|
1190
|
+
"remediation_advice": "1. Turn off the `telnet` service as its traffic is unencrypted.\n2. Consider using an `ssh` service instead as its traffic is encrypted.",
|
|
1191
|
+
"references": [
|
|
1192
|
+
"https://technet.microsoft.com/en-us/library/cc755017(v=ws.10).aspx"
|
|
1193
|
+
]
|
|
1194
|
+
}
|
|
1195
|
+
]
|
|
1196
|
+
},
|
|
1197
|
+
{
|
|
1198
|
+
"id": "mobile_security_misconfiguration",
|
|
1199
|
+
"children": [
|
|
1200
|
+
{
|
|
1201
|
+
"id": "ssl_certificate_pinning",
|
|
1202
|
+
"remediation_advice": "Establish a HTTP Public Key Pinning (HPKP) policy that is communicated to the client application and/or support HPKP in the client application if applicable.",
|
|
1203
|
+
"references": [
|
|
1204
|
+
"https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning",
|
|
1205
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Pinning_Cheat_Sheet.md",
|
|
1206
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.md"
|
|
1207
|
+
]
|
|
1208
|
+
},
|
|
1209
|
+
{
|
|
1210
|
+
"id": "tapjacking",
|
|
1211
|
+
"remediation_advice": "Ensure that the setting filterTouchesWhenObscured is set to true, or that the method onFilterTouchEventForSecurity() is implemented in your app.",
|
|
1212
|
+
"references": [
|
|
1213
|
+
"https://blog.devknox.io/tapjacking-android-prevent/"
|
|
1214
|
+
]
|
|
1215
|
+
},
|
|
1216
|
+
{
|
|
1217
|
+
"id": "clipboard_enabled",
|
|
1218
|
+
"remediation_advice": "Ensure that copy/paste functionality is disabled on sensitive content like credit card numbers, social security numbers etc. as other apps on the same device can access data stored in clipboard.\nThe example below disables clipboard for the `textField` TextView in Android:\n```java\ntextField.setCustomSelectionActionModeCallback(new ActionMode.Callback() {\n public boolean onCreateActionMode(ActionMode actionMode, Menu menu) {\n return false;\n }\n\n public boolean onPrepareActionMode(ActionMode actionMode, Menu menu) {\n return false;\n }\n\n public boolean onActionItemClicked(ActionMode actionMode, MenuItem item) {\n return false;\n }\n\n public void onDestroyActionMode(ActionMode actionMode) {\n }\n});\ntextField.setLongClickable(false);\ntextField.setTextIsSelectable(false);\n```\nThe example below disables clipboard for UITextField in iOS:\n```swift\noverride public func canPerformAction(_ action: Selector, withSender sender: Any?) -> Bool {\n if action == #selector(copy(_:)) || action == #selector(paste(_:)) {\n return false\n }\n return true\n}\n```"
|
|
1219
|
+
}
|
|
1220
|
+
]
|
|
1221
|
+
},
|
|
1222
|
+
{
|
|
1223
|
+
"id": "client_side_injection",
|
|
1224
|
+
"children": [
|
|
1225
|
+
{
|
|
1226
|
+
"id": "binary_planting",
|
|
1227
|
+
"remediation_advice": "1. Use fully qualified paths when loading binaries.\n2. Remove the current working directory (CWD) from the binary search path or if the application depends on loading a binary from the current directory, the path should be obtained first and used to pass in a fully qualified path.\n3. Secure access permissions on a local directory as to not allow a local attacker to plant a malicious binary in a trusted location.",
|
|
1228
|
+
"references": [
|
|
1229
|
+
"http://www.binaryplanting.com/guidelinesDevelopers.htm"
|
|
1230
|
+
]
|
|
1231
|
+
}
|
|
1232
|
+
]
|
|
1233
|
+
},
|
|
1234
|
+
{
|
|
1235
|
+
"id": "automotive_security_misconfiguration",
|
|
1236
|
+
"remediation_advice": "",
|
|
1237
|
+
"children": [
|
|
1238
|
+
{
|
|
1239
|
+
"id": "infotainment",
|
|
1240
|
+
"children": [
|
|
1241
|
+
{
|
|
1242
|
+
"id": "pii_leakage",
|
|
1243
|
+
"remediation_advice": "Do not store PII such as call logs, text messages, and contact lists or names as plaintext in the infotainment system.",
|
|
1244
|
+
"references": [
|
|
1245
|
+
"https://www.prnewswire.com/news-releases/carsblues-vehicle-hack-exploits-vehicle-infotainment-systems-allowing-access-to-call-logs-text-messages-and-more-300751244.html"
|
|
1246
|
+
]
|
|
1247
|
+
},
|
|
1248
|
+
{
|
|
1249
|
+
"id": "code_execution_can_bus_pivot",
|
|
1250
|
+
"remediation_advice": "Filter arbitrary commands and apply input validation to any media devices to prevent executing from the infotainment system. Make sure that the infotainment system is on a sandbox module and does not have direct interaction to the CANbus network.",
|
|
1251
|
+
"references": [
|
|
1252
|
+
"https://motherboard.vice.com/en_us/article/3kvw8y/researchers-hack-car-infotainment-system-and-find-sensitive-user-data-inside",
|
|
1253
|
+
"https://www.bleepingcomputer.com/news/security/you-can-hack-some-mazda-cars-with-a-usb-flash-drive/",
|
|
1254
|
+
"http://illmatics.com/carhacking.html"
|
|
1255
|
+
]
|
|
1256
|
+
},
|
|
1257
|
+
{
|
|
1258
|
+
"id": "code_execution_no_can_bus_pivot",
|
|
1259
|
+
"remediation_advice": "Filter arbitrary commands and apply input validation to any media devices to prevent executing from the infotainment system.",
|
|
1260
|
+
"references": [
|
|
1261
|
+
"https://motherboard.vice.com/en_us/article/3kvw8y/researchers-hack-car-infotainment-system-and-find-sensitive-user-data-inside",
|
|
1262
|
+
"https://www.bleepingcomputer.com/news/security/you-can-hack-some-mazda-cars-with-a-usb-flash-drive/",
|
|
1263
|
+
"http://illmatics.com/carhacking.html"
|
|
1264
|
+
]
|
|
1265
|
+
},
|
|
1266
|
+
{
|
|
1267
|
+
"id": "unauthorized_access_to_services",
|
|
1268
|
+
"remediation_advice": "Filter services that allow you to control the vehicle or infotainment system from being accessed by unauthorized users. Apply authentication mechanisms to certain endpoints.",
|
|
1269
|
+
"references": [
|
|
1270
|
+
"https://www.troyhunt.com/controlling-vehicle-features-of-nissan/"
|
|
1271
|
+
]
|
|
1272
|
+
},
|
|
1273
|
+
{
|
|
1274
|
+
"id": "source_code_dump",
|
|
1275
|
+
"remediation_advice": "Obfuscate the code and find creative ways to break disassemblers and debuggers.",
|
|
1276
|
+
"references": [
|
|
1277
|
+
"https://en.wikipedia.org/wiki/Security_through_obscurity",
|
|
1278
|
+
"https://www.researchgate.net/publication/320859156_Source_Code_Vulnerabilities_in_IoT_Software_Systems"
|
|
1279
|
+
]
|
|
1280
|
+
},
|
|
1281
|
+
{
|
|
1282
|
+
"id": "dos_brick",
|
|
1283
|
+
"remediation_advice": "Filter malicious payloads or string attacks. Apply rate limiting on the app level side.",
|
|
1284
|
+
"references": [
|
|
1285
|
+
"https://www.owasp.org/index.php/Application_Denial_of_Service",
|
|
1286
|
+
"https://www.forbes.com/sites/leemathews/2017/04/10/a-malware-outbreak-is-bricking-insecure-iot-devices/#36603e4a29a3",
|
|
1287
|
+
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Denial_of_Service_Cheat_Sheet.md"
|
|
1288
|
+
]
|
|
1289
|
+
},
|
|
1290
|
+
{
|
|
1291
|
+
"id": "default_credentials",
|
|
1292
|
+
"remediation_advice": "Do not ship infotainment systems with any configured accounts or with default and common usernames and passwords. Do not hard code any backdoor accounts or special access mechanisms.",
|
|
1293
|
+
"references": [
|
|
1294
|
+
"https://www.owasp.org/index.php/Testing_for_default_credentials_(OTG-AUTHN-002)",
|
|
1295
|
+
"https://www.owasp.org/index.php/Configuration#Default_passwords"
|
|
1296
|
+
]
|
|
1297
|
+
}
|
|
1298
|
+
]
|
|
1299
|
+
},
|
|
1300
|
+
{
|
|
1301
|
+
"id": "rf_hub",
|
|
1302
|
+
"children": [
|
|
1303
|
+
{
|
|
1304
|
+
"id": "key_fob_cloning",
|
|
1305
|
+
"remediation_advice": "Implement key fob encryption.",
|
|
1306
|
+
"references": [
|
|
1307
|
+
"https://electronics.howstuffworks.com/gadgets/automotive/unlock-car-door-remote1.htm",
|
|
1308
|
+
"https://www.wired.com/story/hackers-steal-tesla-model-s-seconds-key-fob/"
|
|
1309
|
+
]
|
|
1310
|
+
},
|
|
1311
|
+
{
|
|
1312
|
+
"id": "can_injection_interaction",
|
|
1313
|
+
"remediation_advice": "Implement a secure gateway that prevents CAN Injection from the RF Hub.",
|
|
1314
|
+
"references": [
|
|
1315
|
+
"https://www.reddit.com/r/CarHacking/comments/73qs0x/chrysler_sgw_security_gateway/"
|
|
1316
|
+
]
|
|
1317
|
+
},
|
|
1318
|
+
{
|
|
1319
|
+
"id": "data_leakage_pull_encryption_mechanism",
|
|
1320
|
+
"remediation_advice": "Inspect outgoing traffic from the RF Hub and make sure encryption mechanism cannot be extracted.",
|
|
1321
|
+
"references": [
|
|
1322
|
+
"https://www.networkworld.com/article/2284289/data-leak-prevention-and-encryption--tools-that-can-work-together.html"
|
|
1323
|
+
]
|
|
1324
|
+
},
|
|
1325
|
+
{
|
|
1326
|
+
"id": "unauthorized_access_turn_on",
|
|
1327
|
+
"remediation_advice": ""
|
|
1328
|
+
},
|
|
1329
|
+
{
|
|
1330
|
+
"id": "roll_jam",
|
|
1331
|
+
"remediation_advice": "Update how rolling codes work in vehicles and do over-the-air update capabilities.",
|
|
1332
|
+
"references": [
|
|
1333
|
+
"https://makezine.com/2015/08/11/anatomy-of-the-rolljam-wireless-car-hack/"
|
|
1334
|
+
]
|
|
1335
|
+
},
|
|
1336
|
+
{
|
|
1337
|
+
"id": "replay",
|
|
1338
|
+
"remediation_advice": "Block the transmission of unwanted radio signals and block all forms of the amplification attacks.",
|
|
1339
|
+
"references": [
|
|
1340
|
+
"https://www.wired.com/2017/04/just-pair-11-radio-gadgets-can-steal-car/",
|
|
1341
|
+
"https://www.wired.com/2016/03/study-finds-24-car-models-open-unlocking-ignition-hack/"
|
|
1342
|
+
]
|
|
1343
|
+
},
|
|
1344
|
+
{
|
|
1345
|
+
"id": "relay",
|
|
1346
|
+
"remediation_advice": "Block the transmission of unwanted radio signals and block all forms of the amplification attacks.",
|
|
1347
|
+
"references": [
|
|
1348
|
+
"https://www.wired.com/2017/04/just-pair-11-radio-gadgets-can-steal-car/",
|
|
1349
|
+
"https://www.wired.com/2016/03/study-finds-24-car-models-open-unlocking-ignition-hack/"
|
|
1350
|
+
]
|
|
1351
|
+
}
|
|
1352
|
+
]
|
|
1353
|
+
},
|
|
1354
|
+
{
|
|
1355
|
+
"id": "can",
|
|
1356
|
+
"children": [
|
|
1357
|
+
{
|
|
1358
|
+
"id": "injection_disallowed_messages",
|
|
1359
|
+
"remediation_advice": "Filter malicious CANbus requests or codes especially if not included in the DBC file by implementing a secure gateway.",
|
|
1360
|
+
"references": [
|
|
1361
|
+
"https://news.voyage.auto/an-introduction-to-the-can-bus-how-to-programmatically-control-a-car-f1b18be4f377"
|
|
1362
|
+
]
|
|
1363
|
+
},
|
|
1364
|
+
{
|
|
1365
|
+
"id": "injection_dos",
|
|
1366
|
+
"remediation_advice": "Filter malicious CANbus requests or codes by implementing a secure gateway, as well as limit access to input ports (specifically OBD-II) on automobiles as pointed out by CERT.",
|
|
1367
|
+
"references": [
|
|
1368
|
+
"https://ics-cert.us-cert.gov/alerts/ICS-ALERT-17-209-01",
|
|
1369
|
+
"http://www.autoconnectedcar.com/2017/08/connect-car-can-bus-cant-handle-dos-hacksattacks-researchers-report-can-standard-can-be-changed/"
|
|
1370
|
+
]
|
|
1371
|
+
}
|
|
1372
|
+
]
|
|
1373
|
+
}
|
|
1374
|
+
]
|
|
1375
|
+
},
|
|
1376
|
+
{
|
|
1377
|
+
"id": "indicators_of_compromise",
|
|
1378
|
+
"remediation_advice": ""
|
|
1379
|
+
}
|
|
1380
|
+
]
|
|
1381
|
+
}
|