vrt 0.12.6 → 0.13.1

Sign up to get free protection for your applications and to get access to all the features.
Files changed (29) hide show
  1. checksums.yaml +4 -4
  2. data/lib/data/1.14/deprecated-node-mapping.json +239 -0
  3. data/lib/data/1.14/mappings/cvss_v3/cvss_v3.json +1441 -0
  4. data/lib/data/1.14/mappings/cvss_v3/cvss_v3.schema.json +59 -0
  5. data/lib/data/1.14/mappings/cwe/cwe.json +818 -0
  6. data/lib/data/1.14/mappings/cwe/cwe.schema.json +63 -0
  7. data/lib/data/1.14/mappings/remediation_advice/remediation_advice.json +2080 -0
  8. data/lib/data/1.14/mappings/remediation_advice/remediation_advice.schema.json +75 -0
  9. data/lib/data/1.14/third-party-mappings/remediation_training/secure-code-warrior-links.json +438 -0
  10. data/lib/data/1.14/vrt.schema.json +63 -0
  11. data/lib/data/1.14/vulnerability-rating-taxonomy.json +2730 -0
  12. data/lib/data/1.14.1/deprecated-node-mapping.json +239 -0
  13. data/lib/data/1.14.1/mappings/cvss_v3/cvss_v3.json +1441 -0
  14. data/lib/data/1.14.1/mappings/cvss_v3/cvss_v3.schema.json +59 -0
  15. data/lib/data/1.14.1/mappings/cwe/cwe.json +818 -0
  16. data/lib/data/1.14.1/mappings/cwe/cwe.schema.json +63 -0
  17. data/lib/data/1.14.1/mappings/remediation_advice/remediation_advice.json +2080 -0
  18. data/lib/data/1.14.1/mappings/remediation_advice/remediation_advice.schema.json +75 -0
  19. data/lib/data/1.14.1/third-party-mappings/remediation_training/secure-code-warrior-links.json +438 -0
  20. data/lib/data/1.14.1/vrt.schema.json +63 -0
  21. data/lib/data/1.14.1/vulnerability-rating-taxonomy.json +2730 -0
  22. data/lib/vrt/cross_version_mapping.rb +2 -2
  23. data/lib/vrt/map.rb +2 -2
  24. data/lib/vrt/mapping.rb +9 -5
  25. data/lib/vrt/node.rb +2 -2
  26. data/lib/vrt/third_party_links.rb +1 -1
  27. data/lib/vrt/version.rb +1 -1
  28. data/lib/vrt.rb +1 -1
  29. metadata +36 -14
data/lib/data/1.14.1/mappings/remediation_advice/remediation_advice.json ADDED
@@ -0,0 +1,2080 @@
1
+ {
2
+ "metadata": {
3
+ "default": null,
4
+ "keys": [
5
+ "remediation_advice",
6
+ "references"
7
+ ]
8
+ },
9
+ "content": [
10
+ {
11
+ "id": "server_security_misconfiguration",
12
+ "references": [
13
+ "https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration",
14
+ "http://projects.webappsec.org/w/page/13246959/Server%20Misconfiguration"
15
+ ],
16
+ "children": [
17
+ {
18
+ "id": "server_side_request_forgery_ssrf",
19
+ "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.",
20
+ "references": [
21
+ "https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control",
22
+ "http://projects.webappsec.org/w/page/13246913/Abuse%20of%20Functionality",
23
+ "http://resources.infosecinstitute.com/the-ssrf-vulnerability/",
24
+ "https://www.bishopfox.com/blog/2015/04/vulnerable-by-design-understanding-server-side-request-forgery/",
25
+ "http://niiconsulting.com/checkmate/2015/04/server-side-request-forgery-ssrf/"
26
+ ]
27
+ },
28
+ {
29
+ "id": "unsafe_cross_origin_resource_sharing",
30
+ "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.",
31
+ "references": [
32
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/HTML5_Security_Cheat_Sheet.md#cross-origin-resource-sharing",
33
+ "https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS"
34
+ ]
35
+ },
36
+ {
37
+ "id": "email_verification_bypass",
38
+ "remediation_advice": "1. **Implement Robust Token Validation:** Ensure that any token used for email verification is securely generated and validated. Tokens should be long, random, and use secure hashing algorithms to prevent guessing attacks.\n2. **Secure Transmission:** Use HTTPS to protect the transmission of tokens over the network. Ensure that the tokens are not leaked via URLs in the `Referer` header by instructing users to avoid clicking on links from untrusted sources or by implementing measures to strip sensitive information from URLs.\n3. **Expire Tokens Quickly:** Set a short expiration time for verification tokens to limit the window of opportunity for an attacker. Once a token is used or expires, it should be invalidated immediately to prevent reuse.",
39
+ "references": [
40
+ "https://owasp.org/www-community/attacks/Email_Injection",
41
+ "https://portswigger.net/web-security/email-security"
42
+ ]
43
+ },
44
+ {
45
+ "id": "missing_subresource_integrity",
46
+ "remediation_advice": "1. **Implement SRI:** Add an `integrity` attribute with a base64-encoded hash to `<script>` and `<link>` tags for external resources. \n2. **Validate Hashes:** Always check the hashes of resources yourself before implementation to ensure they haven't been altered. \n3. **Update Hashes Regularly:** Monitor and update the hashes to reflect changes in the external libraries or resources you use.",
47
+ "references": [
48
+ "https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity",
49
+ "https://www.w3.org/TR/SRI/"
50
+ ]
51
+ },
52
+ {
53
+ "id": "software_package_takeover",
54
+ "remediation_advice": "1. **Monitor Dependencies:** Regularly review and update the dependencies in your software projects to ensure they are secure and maintained. Use tools that can automatically check for outdated or vulnerable packages. \n2. **Secure Access Rights:** Restrict and monitor access to package management systems and repositories to prevent unauthorized changes. Use two-factor authentication and strong access controls. \n3. **Verify Package Integrity:** Before deployment, verify the integrity and authenticity of packages using signatures or other verification methods.",
55
+ "references": [
56
+ "https://owasp.org/www-community/attacks/Subdomain_Takeover",
57
+ "https://snyk.io/blog/ten-git-hub-security-best-practices/"
58
+ ]
59
+ },
60
+ {
61
+ "id": "request_smuggling",
62
+ "remediation_advice": "Implement a robust security configuration, including secure parsing and handling of HTTP requests, and consider deploying a Web Application Firewall (WAF) to detect and mitigate potential smuggling attacks.",
63
+ "references": [
64
+ "https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Request_Smuggling_Prevention_Cheat_Sheet.html"
65
+ ]
66
+ },
67
+ {
68
+ "id": "path_traversal",
69
+ "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).",
70
+ "references": [
71
+ "https://www.owasp.org/index.php/Path_Traversal",
72
+ "https://www.owasp.org/index.php/File_System#Path_traversal",
73
+ "http://projects.webappsec.org/w/page/13246952/Path%20Traversal"
74
+ ]
75
+ },
76
+ {
77
+ "id": "directory_listing_enabled",
78
+ "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.",
79
+ "references": [
80
+ "http://projects.webappsec.org/w/page/13246922/Directory%20Indexing"
81
+ ]
82
+ },
83
+ {
84
+ "id": "same_site_scripting",
85
+ "remediation_advice": "As a best practice, do not resolve targets or hostnames to 127.0.0.1 or similar addresses.",
86
+ "references": [
87
+ "http://seclists.org/bugtraq/2008/Jan/270"
88
+ ]
89
+ },
90
+ {
91
+ "id": "ssl_attack_breach_poodle_etc",
92
+ "remediation_advice": "Disable SSL and use updated version of TLS that is not susceptible to the latest variation of the TLS attack.",
93
+ "references": [
94
+ "https://access.redhat.com/articles/1232123",
95
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.md",
96
+ "http://projects.webappsec.org/w/page/13246945/Insufficient%20Transport%20Layer%20Protection"
97
+ ]
98
+ },
99
+ {
100
+ "id": "using_default_credentials",
101
+ "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.",
102
+ "references": [
103
+ "https://www.owasp.org/index.php/Testing_for_default_credentials_(OTG-AUTHN-002)",
104
+ "https://www.owasp.org/index.php/Configuration#Default_passwords",
105
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md"
106
+ ]
107
+ },
108
+ {
109
+ "id": "misconfigured_dns",
110
+ "children": [
111
+ {
112
+ "id": "basic_subdomain_takeover",
113
+ "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.",
114
+ "references": [
115
+ "https://labs.detectify.com/2014/10/21/hostile-subdomain-takeover-using-herokugithubdesk-more/"
116
+ ]
117
+ },
118
+ {
119
+ "id": "high_impact_subdomain_takeover",
120
+ "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.",
121
+ "references": [
122
+ "https://labs.detectify.com/2014/10/21/hostile-subdomain-takeover-using-herokugithubdesk-more/"
123
+ ]
124
+ },
125
+ {
126
+ "id": "zone_transfer",
127
+ "remediation_advice": "Do not allow DNS zone transfers.",
128
+ "references": [
129
+ "https://www.sans.org/reading-room/whitepapers/dns/securing-dns-zone-transfer-868",
130
+ "https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-1999-0532"
131
+ ]
132
+ },
133
+ {
134
+ "id": "missing_caa_record",
135
+ "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.",
136
+ "references": [
137
+ "https://tools.ietf.org/html/rfc6844"
138
+ ]
139
+ }
140
+ ]
141
+ },
142
+ {
143
+ "id": "mail_server_misconfiguration",
144
+ "children": [
145
+ {
146
+ "id": "no_spoofing_protection_on_email_domain",
147
+ "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.",
148
+ "references": [
149
+ "https://mxtoolbox.com/DMARCRecordGenerator.aspx",
150
+ "https://dmarc.org/2016/03/best-practices-for-email-senders/",
151
+ "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"
152
+ ]
153
+ },
154
+ {
155
+ "id": "email_spoofing_to_inbox_due_to_missing_or_misconfigured_dmarc_on_email_domain",
156
+ "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.",
157
+ "references": [
158
+ "https://mxtoolbox.com/DMARCRecordGenerator.aspx",
159
+ "https://dmarc.org/2016/03/best-practices-for-email-senders/",
160
+ "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"
161
+ ]
162
+ },
163
+ {
164
+ "id": "email_spoofing_to_spam_folder",
165
+ "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.",
166
+ "references": [
167
+ "https://dmarc.org/wiki/FAQ#My_mail_is_going_to_the_spam_folder_now.2C_is_DMARC_the_problem.3F",
168
+ "https://mxtoolbox.com/DMARCRecordGenerator.aspx",
169
+ "http://www.openspf.org/SPF_Record_Syntax"
170
+ ]
171
+ },
172
+ {
173
+ "id": "missing_or_misconfigured_spf_and_or_dkim",
174
+ "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.",
175
+ "references": [
176
+ "http://www.openspf.org/SPF_Record_Syntax",
177
+ "http://www.openspf.org/FAQ/Common_mistakes#include"
178
+ ]
179
+ },
180
+ {
181
+ "id": "email_spoofing_on_non_email_domain",
182
+ "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.",
183
+ "references": [
184
+ "https://mxtoolbox.com/DMARCRecordGenerator.aspx",
185
+ "https://dmarc.org/2016/03/best-practices-for-email-senders/",
186
+ "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"
187
+ ]
188
+ }
189
+ ]
190
+ },
191
+ {
192
+ "id": "dbms_misconfiguration",
193
+ "children": [
194
+ {
195
+ "id": "excessively_privileged_user_dba",
196
+ "remediation_advice": "Ensure that the current DBMS session user has the least amount of privilege necessary.",
197
+ "references": [
198
+ "https://www.owasp.org/index.php/Least_privilege"
199
+ ]
200
+ }
201
+ ]
202
+ },
203
+ {
204
+ "id": "lack_of_password_confirmation",
205
+ "children": [
206
+ {
207
+ "id": "change_email_address",
208
+ "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."
209
+ },
210
+ {
211
+ "id": "change_password",
212
+ "remediation_advice": "Use a password confirmation if the original password associated with the account is going to be changed."
213
+ },
214
+ {
215
+ "id": "delete_account",
216
+ "remediation_advice": "Use a password confirmation if there is a request to delete the account."
217
+ },
218
+ {
219
+ "id": "manage_two_fa",
220
+ "remediation_advice": "Use a password confirmation when managing 2FA settings."
221
+ }
222
+ ]
223
+ },
224
+ {
225
+ "id": "no_rate_limiting_on_form",
226
+ "references": [
227
+ "https://www.owasp.org/index.php?title=OWASP_Periodic_Table_of_Vulnerabilities_-_Brute_Force_(Generic)_/_Insufficient_Anti-automation&setlang=en",
228
+ "http://projects.webappsec.org/w/page/13246938/Insufficient%20Anti-automation"
229
+ ],
230
+ "children": [
231
+ {
232
+ "id": "registration",
233
+ "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."
234
+ },
235
+ {
236
+ "id": "login",
237
+ "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."
238
+ },
239
+ {
240
+ "id": "email_triggering",
241
+ "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."
242
+ },
243
+ {
244
+ "id": "sms_triggering",
245
+ "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."
246
+ },
247
+ {
248
+ "id": "change_password",
249
+ "remediation_advice": "1. Use a `CAPTCHA` to limit current password check requests sent when changing account password.\n2. Use a rate limit per IP address to throttle the amount of said requests that can be made in a certain amount of time."
250
+ }
251
+ ]
252
+ },
253
+ {
254
+ "id": "unsafe_file_upload",
255
+ "references": [
256
+ "https://www.owasp.org/index.php/Unrestricted_File_Upload",
257
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Protect_FileUpload_Against_Malicious_File.md"
258
+ ],
259
+ "children": [
260
+ {
261
+ "id": "no_antivirus",
262
+ "remediation_advice": "As a best practice, consider using endpoint protection to check uploaded files for malware and viruses."
263
+ },
264
+ {
265
+ "id": "no_size_limit",
266
+ "remediation_advice": "Have a server-side check for the size limit of file uploads."
267
+ },
268
+ {
269
+ "id": "file_extension_filter_bypass",
270
+ "remediation_advice": "As a best practice, consider using a whitelist of accepted file extensions in order to mitigate against a bypass."
271
+ }
272
+ ]
273
+ },
274
+ {
275
+ "id": "cookie_scoped_to_parent_domain",
276
+ "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.",
277
+ "references": [
278
+ "https://tools.ietf.org/html/rfc6265"
279
+ ]
280
+ },
281
+ {
282
+ "id": "missing_secure_or_httponly_cookie_flag",
283
+ "references": [
284
+ "https://www.owasp.org/index.php/SecureFlag",
285
+ "https://www.owasp.org/index.php/HttpOnly"
286
+ ],
287
+ "children": [
288
+ {
289
+ "id": "session_token",
290
+ "remediation_advice": "Set the `Secure` and `HTTPOnly` cookie flags for the session token."
291
+ },
292
+ {
293
+ "id": "non_session_cookie",
294
+ "remediation_advice": "Consider setting the `Secure` and `HTTPOnly` cookie flags for sensitive cookies."
295
+ }
296
+ ]
297
+ },
298
+ {
299
+ "id": "clickjacking",
300
+ "references": [
301
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Clickjacking_Defense_Cheat_Sheet.md",
302
+ "https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#xfo_bp"
303
+ ],
304
+ "children": [
305
+ {
306
+ "id": "sensitive_action",
307
+ "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/`."
308
+ },
309
+ {
310
+ "id": "form_input",
311
+ "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/`."
312
+ },
313
+ {
314
+ "id": "non_sensitive_action",
315
+ "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."
316
+ }
317
+ ]
318
+ },
319
+ {
320
+ "id": "oauth_misconfiguration",
321
+ "children": [
322
+ {
323
+ "id": "account_takeover",
324
+ "remediation_advice": "Ensure correct implementation of OAuth protocol in order to protect client secrets and tokens, and provide secure access controls.",
325
+ "references": [
326
+ "https://tools.ietf.org/html/rfc6819"
327
+ ]
328
+ },
329
+ {
330
+ "id": "account_squatting",
331
+ "remediation_advice": "In case of OAuth based account registration, ensure that if there is a preexisting account for the same email address and is to be merged, that it will no longer be accessible with its old password."
332
+ },
333
+ {
334
+ "id": "missing_state_parameter",
335
+ "remediation_advice": "The OAuth state parameter is a form of CSRF protection, ensure that it is in place and properly validated."
336
+ },
337
+ {
338
+ "id": "insecure_redirect_uri",
339
+ "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.",
340
+ "references": [
341
+ "https://www.oauth.com/oauth2-servers/redirect-uris/"
342
+ ]
343
+ }
344
+ ]
345
+ },
346
+ {
347
+ "id": "captcha",
348
+ "children": [
349
+ {
350
+ "id": "implementation_vulnerability",
351
+ "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."
352
+ },
353
+ {
354
+ "id": "brute_force",
355
+ "remediation_advice": "As a best practice, consider disallowing multiple attempts to guess the same CAPTCHA."
356
+ },
357
+ {
358
+ "id": "missing",
359
+ "remediation_advice": "As a best practice, consider using CAPTCHAs to prevent automated software from engaging in abusive activities on your site."
360
+ }
361
+ ]
362
+ },
363
+ {
364
+ "id": "exposed_admin_portal",
365
+ "children": [
366
+ {
367
+ "id": "to_internet",
368
+ "remediation_advice": "As a best practice, consider restricting admin portal access to internal users only."
369
+ }
370
+ ]
371
+ },
372
+ {
373
+ "id": "missing_dnssec",
374
+ "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.",
375
+ "references": [
376
+ "https://www.icann.org/resources/pages/dnssec-qaa-2014-01-29-en"
377
+ ]
378
+ },
379
+ {
380
+ "id": "fingerprinting_banner_disclosure",
381
+ "remediation_advice": "As a best practice, do not expose the specific software version."
382
+ },
383
+ {
384
+ "id": "username_enumeration",
385
+ "children": [
386
+ {
387
+ "id": "brute_force",
388
+ "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.\"",
389
+ "references": [
390
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md#authentication-and-error-messages"
391
+ ]
392
+ }
393
+ ]
394
+ },
395
+ {
396
+ "id": "potentially_unsafe_http_method_enabled",
397
+ "references": [
398
+ "https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006)"
399
+ ],
400
+ "children": [
401
+ {
402
+ "id": "options",
403
+ "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."
404
+ },
405
+ {
406
+ "id": "trace",
407
+ "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.",
408
+ "references": [
409
+ "https://www.owasp.org/index.php/Cross_Site_Tracing"
410
+ ]
411
+ }
412
+ ]
413
+ },
414
+ {
415
+ "id": "insecure_ssl",
416
+ "children": [
417
+ {
418
+ "id": "lack_of_forward_secrecy",
419
+ "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.",
420
+ "references": [
421
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.md#rule---prefer-ephemeral-key-exchanges"
422
+ ]
423
+ },
424
+ {
425
+ "id": "insecure_cipher_suite",
426
+ "remediation_advice": "As a best practice, consider supporting only cipher suites that are known to be secure.",
427
+ "references": [
428
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.md#rule---only-support-strong-cryptographic-ciphers"
429
+ ]
430
+ },
431
+ {
432
+ "id": "certificate_error",
433
+ "remediation_advice": "As a best practice, consider resolving any SSL certificate errors in order to establish trust and allow secure connections.",
434
+ "references": [
435
+ "https://cheapsslsecurity.com/blog/google-chrome-ssl-certificate-errors-troubleshoot-guide/"
436
+ ]
437
+ }
438
+ ]
439
+ },
440
+ {
441
+ "id": "rfd",
442
+ "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.",
443
+ "references": [
444
+ "https://www.owasp.org/index.php/Reflected_File_Download"
445
+ ]
446
+ },
447
+ {
448
+ "id": "lack_of_security_headers",
449
+ "children": [
450
+ {
451
+ "id": "x_frame_options",
452
+ "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.",
453
+ "references": [
454
+ "https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#xfo_bp",
455
+ "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options"
456
+ ]
457
+ },
458
+ {
459
+ "id": "cache_control_for_a_non_sensitive_page",
460
+ "remediation_advice": "As a best practice, consider using the `Cache-Control: no-store` 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.",
461
+ "references": [
462
+ "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control"
463
+ ]
464
+ },
465
+ {
466
+ "id": "x_xss_protection",
467
+ "remediation_advice": ""
468
+ },
469
+ {
470
+ "id": "strict_transport_security",
471
+ "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.",
472
+ "references": [
473
+ "https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#hsts",
474
+ "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security"
475
+ ]
476
+ },
477
+ {
478
+ "id": "x_content_type_options",
479
+ "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\".",
480
+ "references": [
481
+ "https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#xcto",
482
+ "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options"
483
+ ]
484
+ },
485
+ {
486
+ "id": "content_security_policy",
487
+ "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.",
488
+ "references": [
489
+ "https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#csp",
490
+ "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy"
491
+ ]
492
+ },
493
+ {
494
+ "id": "public_key_pins",
495
+ "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.",
496
+ "references": [
497
+ "https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#hpkp",
498
+ "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Public-Key-Pins"
499
+ ]
500
+ },
501
+ {
502
+ "id": "x_content_security_policy",
503
+ "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.",
504
+ "references": [
505
+ "https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#csp",
506
+ "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy"
507
+ ]
508
+ },
509
+ {
510
+ "id": "x_webkit_csp",
511
+ "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.",
512
+ "references": [
513
+ "https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#csp",
514
+ "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy"
515
+ ]
516
+ },
517
+ {
518
+ "id": "content_security_policy_report_only",
519
+ "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.",
520
+ "references": [
521
+ "https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#csp",
522
+ "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy-Report-Only"
523
+ ]
524
+ },
525
+ {
526
+ "id": "cache_control_for_a_sensitive_page",
527
+ "remediation_advice": "Add the `Cache-Control` HTTP response header such as `Cache-Control: no-store`, as it will help insure that the browser does not cache sensitive pages."
528
+ }
529
+ ]
530
+ },
531
+ {
532
+ "id": "waf_bypass",
533
+ "children": [
534
+ {
535
+ "id": "direct_server_access",
536
+ "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.",
537
+ "references": [
538
+ "https://blog.christophetd.fr/bypassing-cloudflare-using-internet-wide-scan-data/"
539
+ ]
540
+ }
541
+ ]
542
+ },
543
+ {
544
+ "id": "race_condition",
545
+ "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.",
546
+ "references": [
547
+ "https://lightningsecurity.io/blog/race-conditions/",
548
+ "https://blog.securitycompass.com/moving-beyond-the-owasp-top-10-part-1-race-conditions-912dccbb7c14",
549
+ "https://medium.com/in-the-weeds/fixing-a-race-condition-c8b475fbb994",
550
+ "https://blog.arkency.com/2015/09/testing-race-conditions/",
551
+ "http://www.javacreed.com/what-is-race-condition-and-how-to-prevent-it/",
552
+ "https://blog.golang.org/race-detector"
553
+ ]
554
+ },
555
+ {
556
+ "id": "cache_poisoning",
557
+ "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.",
558
+ "references": [
559
+ "https://portswigger.net/blog/practical-web-cache-poisoning"
560
+ ]
561
+ },
562
+ {
563
+ "id": "bitsquatting",
564
+ "remediation_advice": "As a best practice, consider registering any potential bitsquatting domain names.",
565
+ "references": [
566
+ "http://dinaburg.org/bitsquatting.html"
567
+ ]
568
+ }
569
+ ]
570
+ },
571
+ {
572
+ "id": "server_side_injection",
573
+ "remediation_advice": "Preventing injection requires keeping untrusted data separate from commands and queries.",
574
+ "references": [
575
+ "https://www.owasp.org/index.php/Top_10-2017_A1-Injection"
576
+ ],
577
+ "children": [
578
+ {
579
+ "id": "ldap_injection",
580
+ "remediation_advice": "Implement input validation and sanitization techniques to filter and escape user input before using it in LDAP queries, and utilize parameterized queries or prepared statements to prevent injection attacks.",
581
+ "references": [
582
+ "https://owasp.org/www-community/attacks/LDAP_Injection",
583
+ "https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html"
584
+ ]
585
+ },
586
+ {
587
+ "id": "file_inclusion",
588
+ "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.",
589
+ "references": [
590
+ "http://resources.infosecinstitute.com/file-inclusion-attacks/",
591
+ "https://en.wikipedia.org/wiki/File_inclusion_vulnerability",
592
+ "https://www.cvedetails.com/vulnerability-list/opfileinc-1/file-inclusion.html"
593
+ ]
594
+ },
595
+ {
596
+ "id": "remote_code_execution_rce",
597
+ "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.",
598
+ "references": [
599
+ "https://www.owasp.org/index.php/Command_Injection",
600
+ "https://www.cvedetails.com/vulnerability-list/opec-1/execute-code.html"
601
+ ]
602
+ },
603
+ {
604
+ "id": "sql_injection",
605
+ "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.",
606
+ "references": [
607
+ "https://www.owasp.org/index.php/SQL_Injection",
608
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.md",
609
+ "http://projects.webappsec.org/SQL-Injection",
610
+ "https://www.cvedetails.com/vulnerability-list/opsqli-1/sql-injection.html"
611
+ ]
612
+ },
613
+ {
614
+ "id": "xml_external_entity_injection_xxe",
615
+ "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.",
616
+ "references": [
617
+ "https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing",
618
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.md",
619
+ "http://projects.webappsec.org/XML-External-Entities",
620
+ "https://www.gracefulsecurity.com/xml-external-entity-injection-xxe-vulnerabilities/"
621
+ ]
622
+ },
623
+ {
624
+ "id": "http_response_manipulation",
625
+ "children": [
626
+ {
627
+ "id": "response_splitting_crlf",
628
+ "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.",
629
+ "references": [
630
+ "https://www.owasp.org/index.php/CRLF_Injection",
631
+ "http://projects.webappsec.org/w/page/13246931/HTTP%20Response%20Splitting",
632
+ "https://www.cvedetails.com/vulnerability-list/ophttprs-1/http-response-splitting.html"
633
+ ]
634
+ }
635
+ ]
636
+ },
637
+ {
638
+ "id": "content_spoofing",
639
+ "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.",
640
+ "references": [
641
+ "http://projects.webappsec.org/w/page/13246917/Content%20Spoofing"
642
+ ],
643
+ "children": [
644
+ {
645
+ "id": "iframe_injection",
646
+ "references": [
647
+ "http://resources.infosecinstitute.com/iframe-security-risk/"
648
+ ]
649
+ },
650
+ {
651
+ "id": "impersonation_via_broken_link_hijacking",
652
+ "remediation_advice": "In order to prevent this type of injection consider the following solutions:\n\n1. Keep track of company's public 3rd party accounts, that includes social media. Whenever one is deleted, make sure it is not referenced in the application\n2. Monitor all hyperlinks pointing to 3rd party resources, as well as any other external references for that matter, and make sure that they do not become invalid, e.g. check for change in HTTP response code. In many cases it may be possible for anyone to claim such URL's and share new content.\n3. Always treat all user input as untrusted data."
653
+ },
654
+ {
655
+ "id": "external_authentication_injection",
656
+ "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.",
657
+ "references": [
658
+ "https://www.exploit-db.com/papers/12898/"
659
+ ]
660
+ },
661
+ {
662
+ "id": "flash_based_external_authentication_injection",
663
+ "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."
664
+ },
665
+ {
666
+ "id": "html_content_injection",
667
+ "remediation_advice": "Ensure proper input validation and output encoding to prevent HTML content injection attacks and protect against potential malicious code execution."
668
+ },
669
+ {
670
+ "id": "email_html_injection",
671
+ "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.",
672
+ "references": [
673
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Input_Validation_Cheat_Sheet.md"
674
+ ]
675
+ },
676
+ {
677
+ "id": "email_hyperlink_injection_based_on_email_provider",
678
+ "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.",
679
+ "references": [
680
+ "https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet"
681
+ ]
682
+ },
683
+ {
684
+ "id": "text_injection",
685
+ "remediation_advice": "As a best practice, handle dynamic text input and use a whitelist of proper inputs."
686
+ },
687
+ {
688
+ "id": "homograph_idn_based",
689
+ "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.",
690
+ "references": [
691
+ "https://www.icann.org/news/announcement-2005-02-23-en",
692
+ "http://www.securityfocus.com/bid/12461",
693
+ "https://www.cvedetails.com/cve/CVE-2005-0238/"
694
+ ]
695
+ },
696
+ {
697
+ "id": "rtlo",
698
+ "remediation_advice": "1. If possible avoid allowing Right to Left Override `‮` character in filenames and URLs.\n2. Avoid mixing right-to-left and left-to-right characters in a single name.",
699
+ "references": [
700
+ "https://dl.packetstormsecurity.net/papers/general/righttoleften-override.pdf"
701
+ ]
702
+ }
703
+ ]
704
+ },
705
+ {
706
+ "id": "ssti",
707
+ "remediation_advice": "1. Wherever possible, avoid creating templates from user input. Passing user input into templates as parameters is normally a safe alternative.\n2.If supporting user-submitted templates is a business requirement, consider using a simple logic-less template engine such as Mustache or one provided by the native language like Python's Template. If this is not an option, review the chosen template engine's documentation for hardening advice, and consider rendering the template within a sandboxed execution environment.",
708
+ "references": [
709
+ "https://portswigger.net/kb/issues/00101080_server-side-template-injection"
710
+ ]
711
+ }
712
+ ]
713
+ },
714
+ {
715
+ "id": "broken_authentication_and_session_management",
716
+ "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.",
717
+ "references": [
718
+ "https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication",
719
+ "https://www.owasp.org/index.php/Broken_Authentication_and_Session_Management",
720
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md",
721
+ "http://projects.webappsec.org/Insufficient-Authentication",
722
+ "https://www.cvedetails.com/vulnerability-list/opgpriv-1/gain-privilege.html"
723
+ ],
724
+ "children": [
725
+ {
726
+ "id": "two_fa_bypass",
727
+ "references": [
728
+ "https://www.owasp.org/index.php/Testing_Multiple_Factors_Authentication_(OWASP-AT-009)"
729
+ ]
730
+ },
731
+ {
732
+ "id": "cleartext_transmission_of_session_token",
733
+ "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.",
734
+ "references": [
735
+ "https://www.owasp.org/index.php/Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003)",
736
+ "https://www.owasp.org/index.php/SecureFlag"
737
+ ]
738
+ },
739
+ {
740
+ "id": "weak_login_function",
741
+ "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.",
742
+ "references": [
743
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md#transmit-passwords-only-over-tls-or-other-strong-transport"
744
+ ]
745
+ },
746
+ {
747
+ "id": "session_fixation",
748
+ "remediation_advice": "Always regenerate the session token after the users properly authenticate.",
749
+ "references": [
750
+ "http://projects.webappsec.org/w/page/13246960/Session%20Fixation"
751
+ ]
752
+ },
753
+ {
754
+ "id": "failure_to_invalidate_session",
755
+ "children": [
756
+ {
757
+ "id": "on_logout",
758
+ "remediation_advice": "Properly invalidate the session on the client and server-side when the user logs out of their session.",
759
+ "references": [
760
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Session_Management_Cheat_Sheet.md#manual-session-expiration"
761
+ ]
762
+ },
763
+ {
764
+ "id": "permission_change",
765
+ "remediation_advice": "Review and update the necessary permissions, ensuring they align with the new requirements, and consider implementing a robust permission management system for better control and tracking."
766
+ },
767
+ {
768
+ "id": "on_logout_server_side_only",
769
+ "remediation_advice": "Properly invalidate the session on the server-side when the user logs out of their session.",
770
+ "references": [
771
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Session_Management_Cheat_Sheet.md#manual-session-expiration"
772
+ ]
773
+ },
774
+ {
775
+ "id": "on_password_change",
776
+ "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.",
777
+ "references": [
778
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Session_Management_Cheat_Sheet.md#renew-the-session-id-after-any-privilege-level-change"
779
+ ]
780
+ },
781
+ {
782
+ "id": "all_sessions",
783
+ "remediation_advice": "As a best practice, consider invalidating all user sessions on logout."
784
+ },
785
+ {
786
+ "id": "on_email_change",
787
+ "remediation_advice": "As a best practice, consider invalidating all sessions upon email change."
788
+ },
789
+ {
790
+ "id": "on_two_fa_activation_change",
791
+ "remediation_advice": "As a best practice, consider invalidating all sessions upon 2FA activation or change."
792
+ },
793
+ {
794
+ "id": "long_timeout",
795
+ "remediation_advice": "As a best practice, consider invalidating sessions after a shorter period of time."
796
+ }
797
+ ]
798
+ },
799
+ {
800
+ "id": "concurrent_logins",
801
+ "remediation_advice": "As a best practice, consider disallowing multiple concurrent user sessions or logins."
802
+ }
803
+ ]
804
+ },
805
+ {
806
+ "id": "sensitive_data_exposure",
807
+ "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.",
808
+ "references": [
809
+ "https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure",
810
+ "http://projects.webappsec.org/Information-Leakage",
811
+ "https://blog.detectify.com/2016/07/01/owasp-top-10-sensitive-data-exposure-6/",
812
+ "https://www.cvedetails.com/vulnerability-list/opginf-1/gain-information.html"
813
+ ],
814
+ "children": [
815
+ {
816
+ "id": "disclosure_of_secrets",
817
+ "remediation_advice": "1. Do not store secrets in source code that is publicly accessible such as in a public GitHub repository.\n2. Critically sensitive data should not be transmitted in cleartext. Make sure to only use `HTTPS` whenever transmitting passwords and private API keys.\n3. Set appropriate headers to prevent caching of sensitive data when served to end-user."
818
+ },
819
+ {
820
+ "id": "exif_geolocation_data_not_stripped_from_uploaded_images",
821
+ "remediation_advice": "Remove all sensitive data from `EXIF` geolocation data from images after being uploaded to the server to prevent sensitive data exposure.",
822
+ "references": [
823
+ "http://resources.infosecinstitute.com/metadata-and-information-security/"
824
+ ]
825
+ },
826
+ {
827
+ "id": "visible_detailed_error_page",
828
+ "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.",
829
+ "references": [
830
+ "https://www.owasp.org/index.php/Improper_Error_Handling"
831
+ ]
832
+ },
833
+ {
834
+ "id": "disclosure_of_known_public_information",
835
+ "remediation_advice": "As a best practice, avoid disclosing known public information unnecessarily."
836
+ },
837
+ {
838
+ "id": "token_leakage_via_referer",
839
+ "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."
840
+ },
841
+ {
842
+ "id": "sensitive_token_in_url",
843
+ "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`."
844
+ },
845
+ {
846
+ "id": "non_sensitive_token_in_url",
847
+ "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`."
848
+ },
849
+ {
850
+ "id": "weak_password_reset_implementation",
851
+ "references": [
852
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Forgot_Password_Cheat_Sheet.md",
853
+ "http://projects.webappsec.org/Insufficient-Password-Recovery"
854
+ ],
855
+ "children": [
856
+ {
857
+ "id": "password_reset_token_sent_over_http",
858
+ "remediation_advice": "Avoid sending a password reset token over `HTTP`. A password reset token must always be transmitted via `HTTPS`."
859
+ },
860
+ {
861
+ "id": "token_leakage_via_host_header_poisoning",
862
+ "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.",
863
+ "references": [
864
+ "https://www.acunetix.com/blog/articles/automated-detection-of-host-header-attacks/"
865
+ ]
866
+ }
867
+ ]
868
+ },
869
+ {
870
+ "id": "mixed_content",
871
+ "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.",
872
+ "references": [
873
+ "https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Do_Not_Mix_TLS_and_Non-TLS_Content",
874
+ "https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content"
875
+ ]
876
+ },
877
+ {
878
+ "id": "sensitive_data_hardcoded",
879
+ "children": [
880
+ {
881
+ "id": "oauth_secret",
882
+ "remediation_advice": "Consider using OAuth Implicit Grant to avoid hardcoding the OAuth secret key within the application.",
883
+ "references": [
884
+ "https://tools.ietf.org/html/rfc6749#section-4.2"
885
+ ]
886
+ }
887
+ ]
888
+ },
889
+ {
890
+ "id": "xssi",
891
+ "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.",
892
+ "references": [
893
+ "https://www.scip.ch/en/?labs.20160414"
894
+ ]
895
+ },
896
+ {
897
+ "id": "json_hijacking",
898
+ "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.",
899
+ "references": [
900
+ "http://www.thespanner.co.uk/2011/05/30/json-hijacking/"
901
+ ]
902
+ },
903
+ {
904
+ "id": "via_localstorage_sessionstorage",
905
+ "remediation_advice": "Do not store anything sensitive in localStorage and any critical data in sessionStorage. Stick with properly secured cookies utilizing HTTPOnly and Secure flags",
906
+ "references": [
907
+ "http://michael-coates.blogspot.com/2010/07/html5-local-storage-and-xss.html"
908
+ ]
909
+ }
910
+ ]
911
+ },
912
+ {
913
+ "id": "cross_site_scripting_xss",
914
+ "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.",
915
+ "references": [
916
+ "https://www.owasp.org/index.php/Top_10-2017_A7-Cross-Site_Scripting_(XSS)",
917
+ "https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)",
918
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md",
919
+ "http://projects.webappsec.org/Cross-Site+Scripting",
920
+ "https://www.cvedetails.com/vulnerability-list/opxss-1/xss.html"
921
+ ],
922
+ "children": [
923
+ {
924
+ "id": "trace_method",
925
+ "remediation_advice": "As the TRACE method can be utilized to bypass certain protections, consider disabling the HTTP method TRACE.",
926
+ "references": [
927
+ "https://www.owasp.org/index.php/Cross_Site_Tracing"
928
+ ]
929
+ }
930
+ ]
931
+ },
932
+ {
933
+ "id": "broken_access_control",
934
+ "children": [
935
+ {
936
+ "id": "idor",
937
+ "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.",
938
+ "references": [
939
+ "https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References",
940
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.md"
941
+ ]
942
+ },
943
+ {
944
+ "id": "username_enumeration",
945
+ "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.",
946
+ "references": [
947
+ "https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control",
948
+ "https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure",
949
+ "http://projects.webappsec.org/w/page/13246936/Information%20Leakage"
950
+ ]
951
+ },
952
+ {
953
+ "id": "exposed_sensitive_android_intent",
954
+ "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",
955
+ "references": [
956
+ "https://www.owasp.org/index.php/Mobile_Top_10_2016-M1-Improper_Platform_Usage"
957
+ ]
958
+ },
959
+ {
960
+ "id": "privilege_escalation",
961
+ "remediation_advice": "1. **Least Privilege Principle:** Enforce the least privilege principle by ensuring that users and processes operate using the minimum permissions necessary to perform their tasks. \n2. **Regular Audits:** Conduct regular audits of system permissions and user roles to identify and rectify excessive permissions or misconfigurations. \n3. **Patch Management:** Keep all systems, applications, and services up to date with the latest security patches to close vulnerabilities that could be exploited for privilege escalation.",
962
+ "references": [
963
+ "https://owasp.org/www-community/attacks/Privilege_escalation",
964
+ "https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege"
965
+ ]
966
+ },
967
+ {
968
+ "id": "exposed_sensitive_ios_url_scheme",
969
+ "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.",
970
+ "references": [
971
+ "https://www.owasp.org/index.php/Mobile_Top_10_2016-M1-Improper_Platform_Usage",
972
+ "https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html"
973
+ ]
974
+ }
975
+ ]
976
+ },
977
+ {
978
+ "id": "cross_site_request_forgery_csrf",
979
+ "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.",
980
+ "references": [
981
+ "https://www.owasp.org/index.php/Top_10_2013-A8-Cross-Site_Request_Forgery_(CSRF)",
982
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md",
983
+ "http://projects.webappsec.org/w/page/13246919/Cross%20Site%20Request%20Forgery",
984
+ "https://www.cvedetails.com/vulnerability-list/opcsrf-1/csrf.html"
985
+ ]
986
+ },
987
+ {
988
+ "id": "application_level_denial_of_service_dos",
989
+ "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.",
990
+ "references": [
991
+ "https://www.owasp.org/index.php/Application_Denial_of_Service",
992
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Denial_of_Service_Cheat_Sheet.md",
993
+ "http://projects.webappsec.org/Denial-of-Service",
994
+ "https://www.cvedetails.com/vulnerability-list/opdos-1/denial-of-service.html",
995
+ "https://www.owasp.org/images/d/da/OWASP_IL_7_Application_DOS.pdf"
996
+ ]
997
+ },
998
+ {
999
+ "id": "unvalidated_redirects_and_forwards",
1000
+ "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.",
1001
+ "references": [
1002
+ "https://www.owasp.org/index.php/Top_10_2013-A10-Unvalidated_Redirects_and_Forwards",
1003
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.md",
1004
+ "http://projects.webappsec.org/w/page/13246981/URL%20Redirector%20Abuse"
1005
+ ],
1006
+ "children": [
1007
+ {
1008
+ "id": "tabnabbing",
1009
+ "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.",
1010
+ "references": [
1011
+ "http://www.azarask.in/blog/post/a-new-type-of-phishing-attack/"
1012
+ ]
1013
+ },
1014
+ {
1015
+ "id": "lack_of_security_speed_bump_page",
1016
+ "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."
1017
+ }
1018
+ ]
1019
+ },
1020
+ {
1021
+ "id": "external_behavior",
1022
+ "remediation_advice": "Whenever possible ensure that any security controls that help affect external appliations are in place.",
1023
+ "children": [
1024
+ {
1025
+ "id": "browser_feature",
1026
+ "children": [
1027
+ {
1028
+ "id": "plaintext_password_field",
1029
+ "remediation_advice": "As a best practice, do not allow password fields to be shown in plain text instead of masked."
1030
+ },
1031
+ {
1032
+ "id": "save_password",
1033
+ "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."
1034
+ },
1035
+ {
1036
+ "id": "autocomplete_enabled",
1037
+ "remediation_advice": "As a best practice, do not have Autocomplete enabled by default."
1038
+ },
1039
+ {
1040
+ "id": "autocorrect_enabled",
1041
+ "remediation_advice": "Should the autocorrect feature cause unintended issues, disable autocorrect."
1042
+ },
1043
+ {
1044
+ "id": "aggressive_offline_caching",
1045
+ "remediation_advice": "Avoid caching data unnecessarily, especially sensitive information."
1046
+ }
1047
+ ]
1048
+ }
1049
+ ]
1050
+ },
1051
+ {
1052
+ "id": "insufficient_security_configurability",
1053
+ "references": [
1054
+ "https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration"
1055
+ ],
1056
+ "children": [
1057
+ {
1058
+ "id": "weak_password_policy",
1059
+ "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.\n3. Disallow short password lengths. 8 characters is generally considered a good minimum password length.\n4. Allow for a large maximum password length.\n5. Do not advertise the maximum password length as this will shorten the key space for brute-force guessing.\n6. Disallow previous passwords from being used.\n7. Disallow the password being the same as the email or username.",
1060
+ "references": [
1061
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md#implement-proper-password-strength-controls"
1062
+ ]
1063
+ },
1064
+ {
1065
+ "id": "no_password_policy",
1066
+ "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.\n3. Disallow short password lengths. 8 characters is generally considered a good minimum password length.\n4. Allow for a large maximum password length.\n5. Do not advertise the maximum password length as this will shorten the key space for brute-force guessing.\n6. Disallow previous passwords from being used.\n7. Disallow the password being the same as the email or username.",
1067
+ "references": [
1068
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md#implement-proper-password-strength-controls"
1069
+ ]
1070
+ },
1071
+ {
1072
+ "id": "password_policy_bypass",
1073
+ "remediation_advice": "Consider eliminating any potential for users bypassing your platform's password policy enforcement. For instance if the password policy is only enforced on the client side, consider adding a corresponding validation on the server side."
1074
+ },
1075
+ {
1076
+ "id": "weak_password_reset_implementation",
1077
+ "references": [
1078
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Forgot_Password_Cheat_Sheet.md#step-3-send-a-token-over-a-side-channel",
1079
+ "http://projects.webappsec.org/w/page/13246942/Insufficient%20Password%20Recovery"
1080
+ ],
1081
+ "children": [
1082
+ {
1083
+ "id": "token_is_not_invalidated_after_use",
1084
+ "remediation_advice": "The password reset token should be invalidated immediately after it is used."
1085
+ },
1086
+ {
1087
+ "id": "token_is_not_invalidated_after_email_change",
1088
+ "remediation_advice": "If the email address is changed and there is an active password reset token, the token should be invalidated."
1089
+ },
1090
+ {
1091
+ "id": "token_is_not_invalidated_after_password_change",
1092
+ "remediation_advice": "All existing password reset tokens should be invalidated once the password has been successfully changed."
1093
+ },
1094
+ {
1095
+ "id": "token_has_long_timed_expiry",
1096
+ "remediation_advice": "The password reset token should expire after a limited amount of time. Six hours should be a sufficient expiration time limit."
1097
+ },
1098
+ {
1099
+ "id": "token_is_not_invalidated_after_new_token_is_requested",
1100
+ "remediation_advice": "When a new password reset token is issued, all previous tokens should be invalidated and only the newest token should be active."
1101
+ },
1102
+ {
1103
+ "id": "token_is_not_invalidated_after_login",
1104
+ "remediation_advice": "When the user successfully authenticates, any unused password reset token should be invalidated."
1105
+ }
1106
+ ]
1107
+ },
1108
+ {
1109
+ "id": "verification_of_contact_method_not_required",
1110
+ "remediation_advice": "As a best practice, consider verifying a method of contact, such as email or phone number when a new account is created or when there is an update to the contact information on record."
1111
+ },
1112
+ {
1113
+ "id": "lack_of_notification_email",
1114
+ "remediation_advice": "As a best practice, consider sending a notification email when questionable activity occurs, such as multiple unsuccessful login attempts."
1115
+ },
1116
+ {
1117
+ "id": "weak_registration_implementation",
1118
+ "children": [
1119
+ {
1120
+ "id": "allows_disposable_email_addresses",
1121
+ "remediation_advice": "As a best practice, consider disallowing registrations utilizing known disposable email addresses."
1122
+ }
1123
+ ]
1124
+ },
1125
+ {
1126
+ "id": "weak_two_fa_implementation",
1127
+ "remediation_advice": "Ensure that the second factor authentication is properly configured, has sufficient rate limiting, 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."
1128
+ }
1129
+ ]
1130
+ },
1131
+ {
1132
+ "id": "using_components_with_known_vulnerabilities",
1133
+ "references": [
1134
+ "https://www.owasp.org/index.php/Top_10-2017_A9-Using_Components_with_Known_Vulnerabilities"
1135
+ ],
1136
+ "children": [
1137
+ {
1138
+ "id": "rosetta_flash",
1139
+ "remediation_advice": "Since Flash files cannot start with comments, ensuring that `callback` parameters begin with a comment, such as: `/* */` is a sufficient protection.",
1140
+ "references": [
1141
+ "https://blog.avira.com/understanding-rosetta-flash-vulnerability/",
1142
+ "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4671"
1143
+ ]
1144
+ },
1145
+ {
1146
+ "id": "outdated_software_version",
1147
+ "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."
1148
+ },
1149
+ {
1150
+ "id": "captcha_bypass",
1151
+ "children": [
1152
+ {
1153
+ "id": "ocr_optical_character_recognition",
1154
+ "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."
1155
+ }
1156
+ ]
1157
+ }
1158
+ ]
1159
+ },
1160
+ {
1161
+ "id": "insecure_data_storage",
1162
+ "remediation_advice": "Consider encrypting data for storage, using the strongest encryption algorithms such as AES with a minimum of a 256-bit key size.",
1163
+ "references": [
1164
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cryptographic_Storage_Cheat_Sheet.md",
1165
+ "https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure"
1166
+ ],
1167
+ "children": [
1168
+ {
1169
+ "id": "sensitive_application_data_stored_unencrypted",
1170
+ "children": [
1171
+ {
1172
+ "id": "on_external_storage",
1173
+ "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."
1174
+ }
1175
+ ]
1176
+ },
1177
+ {
1178
+ "id": "server_side_credentials_storage",
1179
+ "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`."
1180
+ },
1181
+ {
1182
+ "id": "screen_caching_enabled",
1183
+ "remediation_advice": "As a best practice, consider preventing background screen caching if the application displays sensitive data."
1184
+ }
1185
+ ]
1186
+ },
1187
+ {
1188
+ "id": "lack_of_binary_hardening",
1189
+ "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.",
1190
+ "references": [
1191
+ "https://wiki.debian.org/Hardening",
1192
+ "https://www.owasp.org/index.php/Mobile_Top_10_2014-M10"
1193
+ ]
1194
+ },
1195
+ {
1196
+ "id": "insecure_data_transport",
1197
+ "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.",
1198
+ "references": [
1199
+ "https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection"
1200
+ ]
1201
+ },
1202
+ {
1203
+ "id": "physical_security_issues",
1204
+ "children": [
1205
+ {
1206
+ "id": "bypass_of_physical_access_control",
1207
+ "remediation_advice": " "
1208
+ },
1209
+ {
1210
+ "id": "weakness_in_physical_access_control",
1211
+ "children": [
1212
+ {
1213
+ "id": "cloneable_key",
1214
+ "remediation_advice": "The 2 most effective are interative locking elements (which can be defeated still by a skilled attacker) or usage of digital key systems such as Assa eCLIQ or Pulse"
1215
+ },
1216
+ {
1217
+ "id": "commonly_keyed_system",
1218
+ "remediation_advice": "Unique keys should be used on any system which intends to be secure, otherwise if keyed to a common key system, the risk needs to be accepted that the key could be obtained if the lock doesn't secure a secure component."
1219
+ },
1220
+ {
1221
+ "id": "master_key_identification",
1222
+ "remediation_advice": "While physical lock systems require the key material to be inside the lock, electonic access control systems can use cryptographicly strong key mechanisms which prevent the key material from being accessable on the device"
1223
+ }
1224
+ ]
1225
+ }
1226
+ ]
1227
+ },
1228
+ {
1229
+ "id": "insecure_os_firmware",
1230
+ "children": [
1231
+ {
1232
+ "id": "command_injection",
1233
+ "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.",
1234
+ "references": [
1235
+ "https://www.owasp.org/index.php/Top_10-2017_A1-Injection",
1236
+ "https://www.owasp.org/index.php/Command_Injection",
1237
+ "http://projects.webappsec.org/OS-Commanding",
1238
+ "https://www.owasp.org/index.php/Injection_Prevention_Cheat_Sheet",
1239
+ "https://www.cvedetails.com/vulnerability-list/opec-1/execute-code.html"
1240
+ ]
1241
+ },
1242
+ {
1243
+ "id": "hardcoded_password",
1244
+ "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.",
1245
+ "references": [
1246
+ "https://www.owasp.org/index.php/Password_Management:_Hardcoded_Password",
1247
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Password_Storage_Cheat_Sheet.md"
1248
+ ]
1249
+ },
1250
+ {
1251
+ "id": "data_not_encrypted_at_rest",
1252
+ "children": [
1253
+ {
1254
+ "id": "non_sensitive",
1255
+ "remediation_advice": "Data within the device should be encrypted at rest, preventing the data from being viewable by a 3rd party attacker."
1256
+ },
1257
+ {
1258
+ "id": "sensitive",
1259
+ "remediation_advice": "Data within the device should be encrypted at rest, preventing the data from being viewable by a 3rd party attacker."
1260
+ }
1261
+ ]
1262
+ },
1263
+ {
1264
+ "id": "failure_to_remove_sensitive_artifacts_from_disk",
1265
+ "remediation_advice": "Implement robust deletion functions which not only reference to the data, but write over the existing data to prevent digital forensic methods of recovery"
1266
+ },
1267
+ {
1268
+ "id": "kiosk_escape_or_breakout",
1269
+ "remediation_advice": "1. Implement vigirous QA testing of applications prior to deployment\n2. Implement robust error logging and catching within the application to prevent crashes\n3. Initiate application restarts in the event of a application crash.\n4. Use Lower Privleged accounts with minimal permissions to lower the impact of a potential kiosk escape"
1270
+ },
1271
+ {
1272
+ "id": "local_administrator_on_default_environment",
1273
+ "remediation_advice": "The usage of Local Administrator accounts on a device is usually not nessicary for the operation, especially with embedded hardware and kiosks. Use of Lower Privleged accounts with minimal permissions and Jails lowers the impact if access by an attacker is acheved."
1274
+ },
1275
+ {
1276
+ "id": "over_permissioned_credentials_on_storage",
1277
+ "remediation_advice": "When provisioning credentials, strict scoping of the credentials to the resources required to operate reduce the impact of an exposure of those credentials."
1278
+ },
1279
+ {
1280
+ "id": "poorly_configured_disk_encryption",
1281
+ "remediation_advice": "1. Use of standard cryptographic libraries reduces the likelyhood of implementation vulnerabilities\n2. Verify your bootloader and encryption systems are up to date to avoid public exploits."
1282
+ },
1283
+ {
1284
+ "id": "poorly_configured_operating_system_security",
1285
+ "remediation_advice": "Following standards such as the NIST or ASD hardening guide allows you to identify known configuration issues and apply configuration changes to prevent this from being exploited further."
1286
+ },
1287
+ {
1288
+ "id": "recovery_of_disk_contains_sensitive_material",
1289
+ "remediation_advice": "Implement robust deletion functions which not only reference to the data, but write over the existing data to prevent digital forensic methods of recovery."
1290
+ },
1291
+ {
1292
+ "id": "shared_credentials_on_storage",
1293
+ "remediation_advice": "Credentials for shared services should be avoided where possible, they allow for a single breach to be escalated to effect an entire organisation. When provisioning a service credential, they should be unique per device and strict scoped to the resources required to operate, to reduce the impact of an exposure of those credentials"
1294
+ },
1295
+ {
1296
+ "id": "weakness_in_firmware_updates",
1297
+ "children": [
1298
+ {
1299
+ "id": "firmware_cannot_be_updated",
1300
+ "remediation_advice": "Implement the ability for the firmware to be upgraded on a device, including an automatic update policy, which will allow for the patch of future security issues on the device."
1301
+ },
1302
+ {
1303
+ "id": "firmware_does_not_validate_update_integrity",
1304
+ "remediation_advice": "Implementation of firmware integrity checking using cryptographic signitures of a certificate is considered best practice, allowing the integrity of the firmware updates to be validated by the device prior to patching."
1305
+ },
1306
+ {
1307
+ "id": "firmware_is_not_encrypted",
1308
+ "remediation_advice": "Implementation of encryption for firmware updates allows for the update data to be protected during transit, and increases the time taken to reverse engineer the firmware used, and future security patches."
1309
+ }
1310
+ ]
1311
+ }
1312
+ ]
1313
+ },
1314
+ {
1315
+ "id": "cryptographic_weakness",
1316
+ "children": [
1317
+ {
1318
+ "id": "insufficient_entropy",
1319
+ "children": [
1320
+ {
1321
+ "id": "limited_rng_entropy_source",
1322
+ "remediation_advice": "1. When using the native entropy sources in a Linux environment, be sure to use /dev/random instead of /dev/urandom. This is because, in the event of depletion of the kernel entropy pool, /dev/random blocks until the level of entropy in the system entropy pool is high enough to ensure high entropy random number generation. In contrast, /dev/urandom does not block and will return low-entropy random numbers in the event of depletion of the system entropy pool.\n\n2. In Windows environments, ensure all elements of the Windows entropy pool exhibit appropriately high levels of randomness.\n\n3. In applications that require large volumes of high-entropy random numbers to be generated, consider using alternative RNGs, such as Intel's Digital Random Number Generator (DRNG).",
1323
+ "references": [
1324
+ "https://www.redhat.com/en/blog/understanding-random-number-generators-and-their-limitations-linux#:~:text=A%20source%20of%20entropy%20(RNG)&text=Random%20number%20generators%20or%20RNGS,unpredictable%20numbers%20as%20its%20output.",
1325
+ "https://blog.cloudflare.com/ensuring-randomness-with-linuxs-random-number-generator/",
1326
+ "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90B.pdf",
1327
+ "https://download.microsoft.com/download/1/c/9/1c9813b8-089c-4fef-b2ad-ad80e79403ba/Whitepaper%20-%20The%20Windows%2010%20random%20number%20generation%20infrastructure.pdf"
1328
+ ]
1329
+ },
1330
+ {
1331
+ "id": "use_of_trng_for_nonsecurity_purpose",
1332
+ "remediation_advice": "1. The random number generation rate of most RNGs is limited, so it is important to draw from RNGs only when entropy is needed for security purposes.\n\n2. Applications should ensure resiliency when drawing from TRNGs by properly handling blocking conditions that may arise when the TRNG blocks due to depletion of the entropy source.\n\n3. Increase potential random number generation rate by integrating multiple, diverse, entropy sources in a secure manner.",
1333
+ "references": [
1334
+ "https://blog.cloudflare.com/ensuring-randomness-with-linuxs-random-number-generator/",
1335
+ "https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf"
1336
+ ]
1337
+ },
1338
+ {
1339
+ "id": "prng_seed_reuse",
1340
+ "remediation_advice": "Pseudo-Random Number Generators (PRNG) use complex algorithms to produce a stream of random bits but require an initial 'seeding,' which determines the outcome of all random numbers generated by the PRNG. Therefore, if an attacker knows the seed value used to initialize the PRNG, it is possible to determine all future random numbers produced by the PRNG. Do not use the same seed value for multiple invocations of PRNG initialization.",
1341
+ "references": [
1342
+ "https://www.sciencedirect.com/science/article/pii/S2212017316304972"
1343
+ ]
1344
+ },
1345
+ {
1346
+ "id": "predictable_prng_seed",
1347
+ "remediation_advice": "Pseudo-Random Number Generators (PRNG) use complex algorithms to produce a stream of random bits but require an initial 'seeding,' which determines the outcome of all random numbers generated by the PRNG. Therefore, if an attacker can predict all or a portion of the seed value used to initialize the PRNG, it is possible to predict the random number stream produced by the PRNG. Per FIPS 140-3, \"Security Requirements for Cryptographic Modules,\" it is acceptable to use the output of a trustworthy PRNG as the seed value for another PRNG. Ensure applications use a randomly-generated seed value by drawing from a trustworth entropy source, such as /dev/random.",
1348
+ "references": [
1349
+ "https://www.sciencedirect.com/science/article/pii/S2212017316304972",
1350
+ "https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402.pdf",
1351
+ "https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf",
1352
+ "https://www.appmarq.com/public/robustness,1039006,CWE-336-Avoid-using-predictable-SecureRandom-Seeds"
1353
+ ]
1354
+ },
1355
+ {
1356
+ "id": "small_seed_space_in_prng",
1357
+ "remediation_advice": "Pseudo-Random Number Generators (PRNG) use complex algorithms to produce a stream of random bits but require an initial 'seeding,' which determines the outcome of all random numbers generated by the PRNG. An insufficiently-sized seed value allows an attacker to brute force the random number stream produced by the PRNG by brute forcing all possible seed values. Ensure the value used as a PRNG seed has a length (in terms of bit size) to guarantee a sufficiently large work-factor to render such brute force attacks infeasible. As a general rule, the number of steps (iterations) required to compromise the seed value should be at least as large as the number of steps (iterations) required to compromise the cryptographic entity (e.g. key) that relies upon the PRNG.",
1358
+ "references": [
1359
+ "https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402.pdf",
1360
+ "https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf",
1361
+ "https://wiki.sei.cmu.edu/confluence/display/c/MSC32-C.+Properly+seed+pseudorandom+number+generators"
1362
+ ]
1363
+ },
1364
+ {
1365
+ "id": "initialization_vector_reuse",
1366
+ "remediation_advice": "Many cryptographic algorithms rely upon an initial block of data, called the 'initialization vector' (IV), in addition to the plaintext being encrypted. If an application reuses the same IV for multiple invocations of an encryption routine, an attacker can use this knowledge to glean the original plaintext from an encrypted stream. Ensure each invocation of an encryption routine uses a different IV.",
1367
+ "references": [
1368
+ "https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf",
1369
+ "https://www.openssl.org/~bodo/tls-cbc.txt",
1370
+ "https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf",
1371
+ "http://www.isaac.cs.berkeley.edu/isaac/mobicom.pdf"
1372
+ ]
1373
+ },
1374
+ {
1375
+ "id": "predictable_initialization_vector",
1376
+ "remediation_advice": "Many cryptographic algorithms rely upon an initial block of data, called the 'initialization vector' (IV), in addition to the plaintext being encrypted. It is critical that it be impossible to predict the IV associated with the plaintext for any given invocation of the encryption routine. This is best achieved by using a newly-generated random number, produced by a trustworthy RNG, for each invocation of the encryption routine.",
1377
+ "references": [
1378
+ "https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf",
1379
+ "https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf",
1380
+ "https://www.cve.org/CVERecord?id=CVE-2011-3389"
1381
+ ]
1382
+ }
1383
+ ]
1384
+ },
1385
+ {
1386
+ "id": "insecure_implementation",
1387
+ "children": [
1388
+ {
1389
+ "id": "missing_cryptographic_step",
1390
+ "remediation_advice": "Oftentimes cryptographic algorithms involve complex and time-consuming mathematical operations to ensure the security of the product (e.g. ciphertext, hash value). In some instances, such as in limited power systems, costly cryptographic steps may be skipped. As a general rule, cryptographic alorithms are difficult to properly implement and developers should rely on well-vetted cryptographic libraries rather than homegrown implementations. When it is necessary to develop a homegrown implementation, always thoroughly review the algorithm specification and properly implement each computational step.",
1391
+ "references": [
1392
+ "https://www.rfc-editor.org/rfc/rfc3565",
1393
+ "https://nvd.nist.gov/vuln/detail/CVE-2022-29053",
1394
+ "https://www.fortiguard.com/psirt/FG-IR-22-158"
1395
+ ]
1396
+ },
1397
+ {
1398
+ "id": "improper_following_of_specification",
1399
+ "remediation_advice": "As a general rule, cryptographic alorithms are difficult to properly implement and developers should rely on well-vetted cryptographic libraries rather than homegrown implementations. When it is necessary to develop a homegrown implementation, ensure the implementation adheres to all requirements for the cryptographic parameters.",
1400
+ "references": [
1401
+ "https://www.rfc-editor.org/rfc/rfc7696",
1402
+ "https://www.rfc-editor.org/rfc/rfc3565"
1403
+ ]
1404
+ }
1405
+ ]
1406
+ },
1407
+ {
1408
+ "id": "weak_hash",
1409
+ "children": [
1410
+ {
1411
+ "id": "lack_of_salt",
1412
+ "remediation_advice": "A hash computed without the addition of a salt value is vulnerable to rainbow table attacks. To prevent such attacks, ensure a unique and randonly-generated salt value is concatenated with the plaintext prior to computing the hash.",
1413
+ "references": [
1414
+ "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#salting",
1415
+ "https://www.rfc-editor.org/rfc/rfc2898#page-6"
1416
+ ]
1417
+ },
1418
+ {
1419
+ "id": "use_of_predictable_salt",
1420
+ "remediation_advice": "When a hash is computing using a predictable salt, the protections afforded by the salt are diminished, leaving the hash vulnerable to rainbow table attacks. Always use a unique and randomly-generated value for the salt, and ensure the length of the salt (in terms of bits) is sufficiently large to prevent brute force attacks. As a general rule, salts used in cryptographic operations should be at least 8 bytes (64 bits) in length.",
1421
+ "references": [
1422
+ "https://www.rfc-editor.org/rfc/rfc2898#page-7"
1423
+ ]
1424
+ },
1425
+ {
1426
+ "id": "predictable_hash_collision",
1427
+ "remediation_advice": "Hash collisions occur when a hashing algorithm generates the same hash value for two (or more) different plaintext inputs. This can be the result of mathematical errors in the algorithm itself, such those found in the MD5 and SHA-1 algorithms. Hash collisions can also occur as the result of incorrect implementation of an otherwise secure algorithm. Always ensure applications make use of unbroken and well-vetted hashing algorithms, and ensure implementations strictly adhere to the requirements of cryptographic parameters as indicated by the relevant specification(s).",
1428
+ "references": [
1429
+ "https://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities",
1430
+ "https://github.com/nim-lang/Nim/issues/10097",
1431
+ "https://www.rfc-editor.org/rfc/rfc6234"
1432
+ ]
1433
+ }
1434
+ ]
1435
+ },
1436
+ {
1437
+ "id": "insufficient_verification_of_data_authenticity",
1438
+ "children": [
1439
+ {
1440
+ "id": "identity_check_value",
1441
+ "remediation_advice": "An Integrity Check Value (ICV) is used to ensure data has not become corrupted during transmission and may incorporate keying material to ensure message authenticity in security sensitive applications. Failure to properly validate the ICV can lead to data corruption and may allow an attacker to impersonate other senders in messages. Ensure the application validates the ICV in all received messages and adheres to the relevant specification(s) with regard to the ICV validation steps.",
1442
+ "references": [
1443
+ "https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf",
1444
+ "https://www.rfc-editor.org/rfc/rfc4302#section-2.6",
1445
+ "https://www.rfc-editor.org/rfc/rfc4302#section-3.3.3"
1446
+ ]
1447
+ },
1448
+ {
1449
+ "id": "cryptographic_signature",
1450
+ "remediation_advice": "A cryptographic signature is used to provide authenticity verification and non-repudiation of data received from another party. Depending on the application context failure to properly validate the cryptographic signature can result in vulnerabilities ranging from unauthorized information disclosure, to user impersonation, or even unauthorized code execution. Ensure the application verifies the cryptographic signature accompanying received data and deny requests containing an invalid cryptographic signature.",
1451
+ "references": [
1452
+ "https://www.internetsociety.org/resources/deploy360/2014/the-two-sides-of-dnssec-signing-and-validation/",
1453
+ "https://vulnerabilityhistory.org/tags/89",
1454
+ "https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-20180926-digsig.html"
1455
+ ]
1456
+ }
1457
+ ]
1458
+ },
1459
+ {
1460
+ "id": "insecure_key_generation",
1461
+ "children": [
1462
+ {
1463
+ "id": "improper_asymmetric_prime_selection",
1464
+ "remediation_advice": "When implementing an asymmetric cryptography algorithm that relies upon prime numbers for public/private keypair generation:\n\n(a). ensure that prime number selection allows sufficiently large prime numbers to be represented;\n(b) ensure there is not mathematical relationship between each of the prime numbers selected; and\n(c) always use uniquely-generated random numbers for prime selection.",
1465
+ "references": [
1466
+ "https://medium.com/curiositypapers/a-complete-explanation-of-rsa-asymmetric-encryption-742c5971e0f",
1467
+ "https://www.schneier.com/blog/archives/2022/03/breaking-rsa-through-insufficiently-random-primes.html",
1468
+ "https://arstechnica.com/information-technology/2022/03/researcher-uses-600-year-old-algorithm-to-crack-crypto-keys-found-in-the-wild/",
1469
+ "https://www.rfc-editor.org/rfc/rfc8017#page-36"
1470
+ ]
1471
+ },
1472
+ {
1473
+ "id": "improper_asymmetric_exponent_selection",
1474
+ "remediation_advice": "When implementing an asymmetric cryptography algorithm that relies upon exponentiation:\n\n(a) ensure that private exponent selection allows for a sufficiently large number to be chosen; and\n(b) always use a uniquely-generated random number for the private exponent.",
1475
+ "references": [
1476
+ "https://medium.com/curiositypapers/a-complete-explanation-of-rsa-asymmetric-encryption-742c5971e0f",
1477
+ "https://www.iacr.org/archive/eurocrypt2000/1807/18070374-new.pdf",
1478
+ "https://www.rfc-editor.org/rfc/rfc8017"
1479
+ ]
1480
+ },
1481
+ {
1482
+ "id": "insufficient_key_stretching",
1483
+ "remediation_advice": "Key stretching is a technique used to increase the entropy of low-entropy keys, such as user-supplied passwords. The technique is usually based on many iterative rounds of cryptographic computations upon the initial low-entropy key and brute forcing vulnerabilities arise if an insufficient number of iterations are applied. Ensure the application adheres to all relevant specification(s) and performs a sufficiently large number of iterations to render the work-factor of brute force attacks infeasible.",
1484
+ "references": [
1485
+ "https://link.springer.com/chapter/10.1007/BFb0030415",
1486
+ "https://www.rfc-editor.org/rfc/rfc2898"
1487
+ ]
1488
+ },
1489
+ {
1490
+ "id": "insufficient_key_space",
1491
+ "remediation_advice": "Most modern cryptogaphic algorithms allow implementers to specify the length of the key used by the algorithm. If an insufficient key length is specified, an attacker can use offline brute force techniques to decrypt the ciphertext without any user input. Ensure the application specifies a sufficiently large minimum cryptographic key length as appropriate for the context or as indicated by relevant regulations and standards. As a general rule, AES-128, RSA-2048, and SHA-256 should be used, at a minimum.",
1492
+ "references": [
1493
+ "https://codeql.github.com/codeql-query-help/cpp/cpp-insufficient-key-size/",
1494
+ "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf"
1495
+ ]
1496
+ },
1497
+ {
1498
+ "id": "key_exchange_without_entity_authentication",
1499
+ "remediation_advice": "When a key exchange is performed without validating the authenticity of the opposite entity, an attacker is able to impersonate a trusted entity and compromise the confidentiality of the encrypted data. Ensure the application properly verifies the identity of the opposite party during key exchange using context appropriate mechanisms, as indiciated in the relevant standard(s) and specification(s).",
1500
+ "references": [
1501
+ "https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf",
1502
+ "https://www.rfc-editor.org/rfc/rfc6071#page-17",
1503
+ "https://www.rfc-editor.org/rfc/rfc5246"
1504
+ ]
1505
+ }
1506
+ ]
1507
+ },
1508
+ {
1509
+ "id": "key_reuse",
1510
+ "children": [
1511
+ {
1512
+ "id": "lack_of_perfect_forward_secrecy",
1513
+ "remediation_advice": "Perfect Forward Secrecy (PFS) is a technique used to minimize the impact of compromise of an entity's longterm private key by negotiating an ephemeral keypair for each new session between two parties. Without PFS, compromise of an entity's longterm private key results in compromise of all historical and future session keys based thereupon, meaning any recorded encrypted traffic can then be decrypted. Ensure the application enables PFS for the encryption protocols implemented, as indicated by the relevant standard(s) and specification(s).",
1514
+ "references": [
1515
+ "https://avinetworks.com/glossary/perfect-forward-secrecy/#:~:text=Without%20perfect%20forward%20secrecy%2C%20an,primary%20secret%20with%20each%20client.",
1516
+ "https://medium.com/asecuritysite-when-bob-met-alice/forward-secrecy-and-ephemeral-keys-guarding-against-data-breaches-in-the-future-b709295c6e5a",
1517
+ "https://www.rfc-editor.org/rfc/rfc7525#page-18"
1518
+ ]
1519
+ },
1520
+ {
1521
+ "id": "intra_environment",
1522
+ "remediation_advice": "Cryptographic key reuse occurs when the same key is used for more than one purpose. When the same key is used for multiple purposes within the context of a single environment (e.g. individual customer in a multi-tenant application) an attacker can leverage knowledge of the key to gain unauthorized access to other information or privileges protected by the same key. Ensure all application components, such as information and authentication tokens, are appropriately grouped into separate trust zones and protected by separate cryptographic keys."
1523
+ },
1524
+ {
1525
+ "id": "inter_environment",
1526
+ "remediation_advice": "Cryptographic key reuse occurs when the same key is used for more than one purpose. When the same key is used between multiple application contexts, such as different customer environments in a multi-tenancy application, an attacker can gain unauthorized access to other users' information and may be able to impersonate other users to achieve privilege escalation. Ensure the application uses unique cryptographic keys for each application context and do not reuse keys across trust zones."
1527
+ }
1528
+ ]
1529
+ },
1530
+ {
1531
+ "id": "broken_cryptography",
1532
+ "children": [
1533
+ {
1534
+ "id": "use_of_broken_cryptographic_primitive",
1535
+ "remediation_advice": "The use of broken, weak, or flawed cryptographic algorithms can allow an attacker to decrypt sensistive information. Ensure the application makes use of only trustworthy cryprographic algorithms as indicated by relevant security standard(s) and regulation(s).",
1536
+ "references": [
1537
+ "https://codeql.github.com/codeql-query-help/java/java-weak-cryptographic-algorithm/",
1538
+ "https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexa.pdf",
1539
+ "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf"
1540
+ ]
1541
+ },
1542
+ {
1543
+ "id": "use_of_vulnerable_cryptographic_library",
1544
+ "remediation_advice": "The identification, patching, and disclosure of vulnerabilities in third-party libraries, including cryptographic libraries, is a daily occurrence. In some cases, cryptographic libraries are deemed 'broken' and deprecated. Ensure the application is updated to include the latest secure version of all third-party cryptographic libraries and replace known 'broken' cryptographic libraries with secure alternatives.",
1545
+ "references": [
1546
+ "https://www.ubiqsecurity.com/bouncy-castle-and-the-impact-of-cryptographic-vulnerabilities/",
1547
+ "https://blog.cryptographyengineering.com/2013/09/20/rsa-warns-developers-against-its-own/"
1548
+ ]
1549
+ }
1550
+ ]
1551
+ },
1552
+ {
1553
+ "id": "side_channel_attack",
1554
+ "children": [
1555
+ {
1556
+ "id": "padding_oracle_attack",
1557
+ "remediation_advice": "A padding oracle attack occurs when the application reveals information about the validity of padding in data provided for decryption. By making repeated attempts to decrypt attacker-controlled data, an attacker can use the information gleaned from the padding oracle to derive the encryption key. Ensure the application produces non-descript error messages when decrypting user-supplied data. Application responses also must not vary between different types of failure, such that an attacker cannot glean from the error that a padding exception has occurred.",
1558
+ "references": [
1559
+ "https://archiv.infsec.ethz.ch/education/fs08/secsem/Manger01.pdf",
1560
+ "https://research.nccgroup.com/2021/02/17/cryptopals-exploiting-cbc-padding-oracles/",
1561
+ "https://flast101.github.io/padding-oracle-attack-explained/"
1562
+ ]
1563
+ },
1564
+ {
1565
+ "id": "timing_attack",
1566
+ "remediation_advice": "A timing attack occurs when the amount of time the application takes to complete a cryptographic operation is related to the data provided by the user. By making repeated attempts to decrypt attacker-controlled data, an attacker can use the information gleaned from this attack to derive the encryption key. Ensure the application implements constant-time cryptographic algorithms, which always take the same amount of time to complete regardless of the input.",
1567
+ "references": [
1568
+ "https://research.kudelskisecurity.com/2013/12/13/timing-attacks-part-1/",
1569
+ "https://www.bearssl.org/constanttime.html",
1570
+ "https://www.chosenplaintext.ca/articles/beginners-guide-constant-time-cryptography.html"
1571
+ ]
1572
+ },
1573
+ {
1574
+ "id": "power_analysis_attack",
1575
+ "remediation_advice": "Power analysis attacks are made possible when the power consumption of a system or individual circuit is dependent upon the outcome or state of specific steps of the cryptographic algorithm implementation. Ensure the outcome of an individual step, or a group of steps, in a cryptographic algorithm implementation cannot be directly observed via the electrical state of any given circuit board trace or component. Ensure power consumption of the system as a whole is decoupled from the state of cryptographic operations performed by the system through the use of power supply capacitance measures.",
1576
+ "references": [
1577
+ "https://www.proquest.com/openview/45733f2da135a88fba879f038db4d319/1?pq-origsite=gscholar&cbl=18750&diss=y",
1578
+ "https://web.wpi.edu/Pubs/E-project/Available/E-project-122211-215512/unrestricted/Power_analysis.pdf",
1579
+ "https://eprint.iacr.org/2014/204.pdf",
1580
+ "https://ieeexplore.ieee.org/document/6730921"
1581
+ ]
1582
+ },
1583
+ {
1584
+ "id": "emanations_attack",
1585
+ "remediation_advice": "Emanations attacks are made possible when the outcome or state of specific steps of the cryptographic algorithm implementation result in changes to the electromagnetic emanations produced by the physical system on which the application is running. Remediation of emanations leakage vulnerabilities is highly-dependent upon the application context but some general countermeasures are effective in most instances. Ensure the application's implementation of each step of cryptographic algorithm processing results in uniform use of processor cycles, power, and features. In some cases, this may involve the incorporation of less efficient code, in order to achieve a uniform emanations profile for all possible outcomes of each cryptographic step. Additionally, incorporate EMF shielding into the physical device design to reduce detectable emanations from the device.",
1586
+ "references": [
1587
+ "https://www.cs.tau.ac.il/~tromer/mobilesc/",
1588
+ "https://www.cs.tau.ac.il/~tromer/ecdh/",
1589
+ "https://eprint.iacr.org/2016/231.pdf",
1590
+ "https://eprint.iacr.org/2016/129.pdf"
1591
+ ]
1592
+ },
1593
+ {
1594
+ "id": "differential_fault_analysis",
1595
+ "remediation_advice": "Differential fault analysis attacks are made possible when the outcome or state of specific steps of the cryptographic algorithm implementation can be gleaned by changes in the application's (or system's) response to specially-crafted fault conditions. To prevent such attacks, applications and systems should always revert to a known and uniform state upon the occurrence of faults. This may be achieved using a variety of methods, the effectiveness of which will vary depending upon context, such as uniform exception handling, restoration of a saved state, or system reset.",
1596
+ "references": [
1597
+ "https://link.springer.com/content/pdf/10.1007/BFb0052259.pdf?pdf=inline%20link",
1598
+ "https://ieeexplore.ieee.org/document/6976633"
1599
+ ]
1600
+ }
1601
+ ]
1602
+ },
1603
+ {
1604
+ "id": "use_of_expired_cryptographic_key_or_cert",
1605
+ "remediation_advice": "This vulnerabily occurs when:\n\n (a). the application fails to verify the expiration date of a certificate provided by another entity has not passed;\n(b) the application fails to verify the certificate provided by another entity has not been revoked by the issuing authority; or\n(c). the application relies upon manual key management and does not provide a means of verifying the lifecycle of keys in use. Ensure the application verifies the certificate produced by the opposite entity has not expired or been revoked, and provide the application user with sufficient information about how to proceed. Ensure the application implements mechanisms to determine the lifecycle of manually-managed cryptographic keys and reject attempts to use expired keys.",
1606
+ "references": [
1607
+ "https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf"
1608
+ ]
1609
+ },
1610
+ {
1611
+ "id": "incomplete_cleanup_of_keying_material",
1612
+ "remediation_advice": "Ensure the application erases all non-volatile copies of sensitive cryptographic data in memory or other non-volatile storage when no longer needed by the application. Ensure the application does not retain sensitive cryptographic data in memory longer than necessary by storing the data in protected volatile storage (e.g. TPM) and open/close handles to the data upon each new invocation of the cryptographic routine.",
1613
+ "references": [
1614
+ "https://documentation-service.arm.com/static/624af896b059dc5ff9a8fbda"
1615
+ ]
1616
+ }
1617
+ ]
1618
+ },
1619
+ {
1620
+ "id": "privacy_concerns",
1621
+ "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.",
1622
+ "references": [
1623
+ "https://www.owasp.org/index.php/Privacy_Violation",
1624
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/User_Privacy_Protection_Cheat_Sheet.md"
1625
+ ]
1626
+ },
1627
+ {
1628
+ "id": "network_security_misconfiguration",
1629
+ "children": [
1630
+ {
1631
+ "id": "telnet_enabled",
1632
+ "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.",
1633
+ "references": [
1634
+ "https://technet.microsoft.com/en-us/library/cc755017(v=ws.10).aspx"
1635
+ ]
1636
+ }
1637
+ ]
1638
+ },
1639
+ {
1640
+ "id": "mobile_security_misconfiguration",
1641
+ "children": [
1642
+ {
1643
+ "id": "ssl_certificate_pinning",
1644
+ "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.",
1645
+ "references": [
1646
+ "https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning",
1647
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Pinning_Cheat_Sheet.md",
1648
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.md"
1649
+ ]
1650
+ },
1651
+ {
1652
+ "id": "tapjacking",
1653
+ "remediation_advice": "Ensure that the setting filterTouchesWhenObscured is set to true, or that the method onFilterTouchEventForSecurity() is implemented in your app.",
1654
+ "references": [
1655
+ "https://blog.devknox.io/tapjacking-android-prevent/"
1656
+ ]
1657
+ },
1658
+ {
1659
+ "id": "clipboard_enabled",
1660
+ "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\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```\n\nThe example below disables clipboard for UITextField in iOS:\n\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```\n\n"
1661
+ },
1662
+ {
1663
+ "id": "auto_backup_allowed_by_default",
1664
+ "remediation_advice": "Consider disabling auto backup of any sensitive application data. In Android you can disable auto backup by setting `android:allowBackup` in your app manifest file to false.",
1665
+ "references": [
1666
+ "https://developer.android.com/guide/topics/data/autobackup"
1667
+ ]
1668
+ }
1669
+ ]
1670
+ },
1671
+ {
1672
+ "id": "client_side_injection",
1673
+ "children": [
1674
+ {
1675
+ "id": "binary_planting",
1676
+ "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.",
1677
+ "references": [
1678
+ "http://www.binaryplanting.com/guidelinesDevelopers.htm"
1679
+ ]
1680
+ }
1681
+ ]
1682
+ },
1683
+ {
1684
+ "id": "automotive_security_misconfiguration",
1685
+ "remediation_advice": "",
1686
+ "children": [
1687
+ {
1688
+ "id": "infotainment_radio_head_unit",
1689
+ "children": [
1690
+ {
1691
+ "id": "sensitive_data_leakage_exposure",
1692
+ "remediation_advice": "Do not store sensitive data such as call logs, text messages, and contact lists or names as plaintext in the infotainment system.",
1693
+ "references": [
1694
+ "https://www.prnewswire.com/news-releases/carsblues-vehicle-hack-exploits-vehicle-infotainment-systems-allowing-access-to-call-logs-text-messages-and-more-300751244.html"
1695
+ ]
1696
+ },
1697
+ {
1698
+ "id": "ota_firmware_manipulation",
1699
+ "remediation_advice": "Implement key signing and firmware verification.",
1700
+ "references": [
1701
+ "https://www.wired.com/2015/02/firmware-vulnerable-hacking-can-done/"
1702
+ ]
1703
+ },
1704
+ {
1705
+ "id": "code_execution_can_bus_pivot",
1706
+ "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.",
1707
+ "references": [
1708
+ "https://motherboard.vice.com/en_us/article/3kvw8y/researchers-hack-car-infotainment-system-and-find-sensitive-user-data-inside",
1709
+ "https://www.bleepingcomputer.com/news/security/you-can-hack-some-mazda-cars-with-a-usb-flash-drive/",
1710
+ "http://illmatics.com/carhacking.html"
1711
+ ]
1712
+ },
1713
+ {
1714
+ "id": "code_execution_no_can_bus_pivot",
1715
+ "remediation_advice": "Filter arbitrary commands and apply input validation to any media devices to prevent executing from the infotainment system.",
1716
+ "references": [
1717
+ "https://motherboard.vice.com/en_us/article/3kvw8y/researchers-hack-car-infotainment-system-and-find-sensitive-user-data-inside",
1718
+ "https://www.bleepingcomputer.com/news/security/you-can-hack-some-mazda-cars-with-a-usb-flash-drive/",
1719
+ "http://illmatics.com/carhacking.html"
1720
+ ]
1721
+ },
1722
+ {
1723
+ "id": "unauthorized_access_to_services",
1724
+ "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.",
1725
+ "references": [
1726
+ "https://www.troyhunt.com/controlling-vehicle-features-of-nissan/"
1727
+ ]
1728
+ },
1729
+ {
1730
+ "id": "source_code_dump",
1731
+ "remediation_advice": "Obfuscate the code and find creative ways to break disassemblers and debuggers.",
1732
+ "references": [
1733
+ "https://en.wikipedia.org/wiki/Security_through_obscurity",
1734
+ "https://www.researchgate.net/publication/320859156_Source_Code_Vulnerabilities_in_IoT_Software_Systems"
1735
+ ]
1736
+ },
1737
+ {
1738
+ "id": "dos_brick",
1739
+ "remediation_advice": "Filter malicious payloads or string attacks. Apply rate limiting on the app level side.",
1740
+ "references": [
1741
+ "https://www.owasp.org/index.php/Application_Denial_of_Service",
1742
+ "https://www.forbes.com/sites/leemathews/2017/04/10/a-malware-outbreak-is-bricking-insecure-iot-devices/#36603e4a29a3",
1743
+ "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Denial_of_Service_Cheat_Sheet.md"
1744
+ ]
1745
+ },
1746
+ {
1747
+ "id": "default_credentials",
1748
+ "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.",
1749
+ "references": [
1750
+ "https://www.owasp.org/index.php/Testing_for_default_credentials_(OTG-AUTHN-002)",
1751
+ "https://www.owasp.org/index.php/Configuration#Default_passwords"
1752
+ ]
1753
+ }
1754
+ ]
1755
+ },
1756
+ {
1757
+ "id": "rf_hub",
1758
+ "children": [
1759
+ {
1760
+ "id": "key_fob_cloning",
1761
+ "remediation_advice": "Implement key fob encryption.",
1762
+ "references": [
1763
+ "https://electronics.howstuffworks.com/gadgets/automotive/unlock-car-door-remote1.htm",
1764
+ "https://www.wired.com/story/hackers-steal-tesla-model-s-seconds-key-fob/"
1765
+ ]
1766
+ },
1767
+ {
1768
+ "id": "can_injection_interaction",
1769
+ "remediation_advice": "Implement a secure gateway that prevents CAN Injection from the RF Hub.",
1770
+ "references": [
1771
+ "https://www.reddit.com/r/CarHacking/comments/73qs0x/chrysler_sgw_security_gateway/"
1772
+ ]
1773
+ },
1774
+ {
1775
+ "id": "data_leakage_pull_encryption_mechanism",
1776
+ "remediation_advice": "Inspect outgoing traffic from the RF Hub and make sure encryption mechanism cannot be extracted.",
1777
+ "references": [
1778
+ "https://www.networkworld.com/article/2284289/data-leak-prevention-and-encryption--tools-that-can-work-together.html"
1779
+ ]
1780
+ },
1781
+ {
1782
+ "id": "unauthorized_access_turn_on",
1783
+ "remediation_advice": ""
1784
+ },
1785
+ {
1786
+ "id": "roll_jam",
1787
+ "remediation_advice": "Update how rolling codes work in vehicles and do over-the-air update capabilities.",
1788
+ "references": [
1789
+ "https://makezine.com/2015/08/11/anatomy-of-the-rolljam-wireless-car-hack/"
1790
+ ]
1791
+ },
1792
+ {
1793
+ "id": "replay",
1794
+ "remediation_advice": "Block the transmission of unwanted radio signals and block all forms of the amplification attacks.",
1795
+ "references": [
1796
+ "https://www.wired.com/2017/04/just-pair-11-radio-gadgets-can-steal-car/",
1797
+ "https://www.wired.com/2016/03/study-finds-24-car-models-open-unlocking-ignition-hack/"
1798
+ ]
1799
+ },
1800
+ {
1801
+ "id": "relay",
1802
+ "remediation_advice": "Block the transmission of unwanted radio signals and block all forms of the amplification attacks.",
1803
+ "references": [
1804
+ "https://www.wired.com/2017/04/just-pair-11-radio-gadgets-can-steal-car/",
1805
+ "https://www.wired.com/2016/03/study-finds-24-car-models-open-unlocking-ignition-hack/"
1806
+ ]
1807
+ }
1808
+ ]
1809
+ },
1810
+ {
1811
+ "id": "can",
1812
+ "children": [
1813
+ {
1814
+ "id": "injection_battery_management_system",
1815
+ "remediation_advice": "Filter malicious CANBus requests or codes that can be injected into the battery management system.",
1816
+ "references": [
1817
+ "https://i.blackhat.com/USA-20/Wednesday/us-20-Kiley-Reverse-Engineering-The-Tesla-Battery-Management-System-To-Increase-Power-Available.pdf"
1818
+ ]
1819
+ },
1820
+ {
1821
+ "id": "injection_steering_control",
1822
+ "remediation_advice": "Filter malicious CANBus requests or codes that can be injected into the steering control.",
1823
+ "references": [
1824
+ "https://jwcn-eurasipjournals.springeropen.com/articles/10.1186/s13638-019-1484-3"
1825
+ ]
1826
+ },
1827
+ {
1828
+ "id": "injection_pyrotechnical_device_deployment_tool",
1829
+ "remediation_advice": "Countermeasures of this attack include selection of suitable technologies, hard-wired plausibility checks, usage of cryptography, and hardening against brute force attacks of the keys or algorithms.",
1830
+ "references": [
1831
+ "https://www.rapid7.com/db/modules/post/hardware/automotive/pdt/"
1832
+ ]
1833
+ },
1834
+ {
1835
+ "id": "injection_headlights",
1836
+ "remediation_advice": "Filter malicious CANBus requests or codes that can be injected into the headlights.",
1837
+ "references": [
1838
+ "https://jwcn-eurasipjournals.springeropen.com/articles/10.1186/s13638-019-1484-3"
1839
+ ]
1840
+ },
1841
+ {
1842
+ "id": "injection_sensors",
1843
+ "remediation_advice": "Filter malicious CANBus requests or codes that can be used to manipulate the sensors.",
1844
+ "references": [
1845
+ "https://jwcn-eurasipjournals.springeropen.com/articles/10.1186/s13638-019-1484-3"
1846
+ ]
1847
+ },
1848
+ {
1849
+ "id": "injection_vehicle_anti_theft_systems",
1850
+ "remediation_advice": "Filter malicious CANBus requests or codes that can be used to manipulate the Vehicle Anti-theft Systems.",
1851
+ "references": [
1852
+ "https://jwcn-eurasipjournals.springeropen.com/articles/10.1186/s13638-019-1484-3"
1853
+ ]
1854
+ },
1855
+ {
1856
+ "id": "injection_powertrain",
1857
+ "remediation_advice": "Filter malicious CANBus requests or codes that can be used to manipulate the Powertrain.",
1858
+ "references": [
1859
+ "https://jwcn-eurasipjournals.springeropen.com/articles/10.1186/s13638-019-1484-3"
1860
+ ]
1861
+ },
1862
+ {
1863
+ "id": "injection_basic_safety_message",
1864
+ "remediation_advice": "Filter malicious CANBus requests or codes that can be used to manipulate the Basic Safety Message.",
1865
+ "references": [
1866
+ "https://jwcn-eurasipjournals.springeropen.com/articles/10.1186/s13638-019-1484-3"
1867
+ ]
1868
+ },
1869
+ {
1870
+ "id": "injection_disallowed_messages",
1871
+ "remediation_advice": "Filter malicious CANbus requests or codes especially if not included in the DBC file by implementing a secure gateway.",
1872
+ "references": [
1873
+ "https://news.voyage.auto/an-introduction-to-the-can-bus-how-to-programmatically-control-a-car-f1b18be4f377"
1874
+ ]
1875
+ },
1876
+ {
1877
+ "id": "injection_dos",
1878
+ "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.",
1879
+ "references": [
1880
+ "https://ics-cert.us-cert.gov/alerts/ICS-ALERT-17-209-01",
1881
+ "http://www.autoconnectedcar.com/2017/08/connect-car-can-bus-cant-handle-dos-hacksattacks-researchers-report-can-standard-can-be-changed/"
1882
+ ]
1883
+ }
1884
+ ]
1885
+ },
1886
+ {
1887
+ "id": "battery_management_system",
1888
+ "children": [
1889
+ {
1890
+ "id": "firmware_dump",
1891
+ "remediation_advice": "Implement secure boot, obfuscate the code, and compression algorithm with hardware-backed dictionary. Find creative ways to break disassemblers and debuggers.",
1892
+ "references": [
1893
+ "https://en.wikipedia.org/wiki/Security_through_obscurityhttps://www.researchgate.net/publication/320859156_Source_Code_Vulnerabilities_in_IoT_Software_Systems"
1894
+ ]
1895
+ },
1896
+ {
1897
+ "id": "fraudulent_interface",
1898
+ "remediation_advice": "Protect and make sure the battery management system provides prevention from operating outside its safe operating area.",
1899
+ "references": [
1900
+ "https://en.wikipedia.org/wiki/Battery_management_system"
1901
+ ]
1902
+ }
1903
+ ]
1904
+ },
1905
+ {
1906
+ "id": "gnss_gps",
1907
+ "children": [
1908
+ {
1909
+ "id": "spoofing",
1910
+ "remediation_advice": "Implement a system that detects GPS spoofing which evaluates or prevents the system from believing and acting on false data.",
1911
+ "references": [
1912
+ "https://www.kaspersky.com/blog/gps-spoofing-protection/26837/"
1913
+ ]
1914
+ }
1915
+ ]
1916
+ },
1917
+ {
1918
+ "id": "immobilizer",
1919
+ "children": [
1920
+ {
1921
+ "id": "engine_start",
1922
+ "remediation_advice": "Implement a secure gateway to protect against immobilizer attacks, assign significant bytes in data and a method to send an abnormal signal overwriting the false data when a communication error has occurred.",
1923
+ "references": [
1924
+ "https://www.kaspersky.com/blog/36c3-immobilizers/32419/"
1925
+ ]
1926
+ }
1927
+ ]
1928
+ },
1929
+ {
1930
+ "id": "abs",
1931
+ "children": [
1932
+ {
1933
+ "id": "unintended_acceleration_brake",
1934
+ "remediation_advice": "Implement a secure gateway to protect against ABS attacks.",
1935
+ "references": [
1936
+ "https://jwcn-eurasipjournals.springeropen.com/articles/10.1186/s13638-019-1484-3"
1937
+ ]
1938
+ }
1939
+ ]
1940
+ },
1941
+ {
1942
+ "id": "rsu",
1943
+ "children": [
1944
+ {
1945
+ "id": "sybil_attack",
1946
+ "remediation_advice": "Known approaches to Sybil attack prevention include identity validation, social trust graph algorithms, or economic costs, personhood validation, and application-specific defenses.",
1947
+ "references": [
1948
+ "https://en.wikipedia.org/wiki/Sybil_attack"
1949
+ ]
1950
+ }
1951
+ ]
1952
+ }
1953
+ ]
1954
+ },
1955
+ {
1956
+ "id": "ai_application_security",
1957
+ "children": [
1958
+ {
1959
+ "id": "llm_security",
1960
+ "children": [
1961
+ {
1962
+ "id": "prompt_injection",
1963
+ "remediation_advice": "Implement robust input sanitization to prevent malicious or unintended prompt execution. Establish strict access controls and usage monitoring to detect and prevent unauthorized or anomalous interactions with the LLM. Regularly review and update the model's training data and algorithms to reduce vulnerabilities. Educate users and developers on safe interaction practices with AI systems.",
1964
+ "references": [
1965
+ "https://developer.nvidia.com/blog/securing-llm-systems-against-prompt-injection"
1966
+ ]
1967
+ },
1968
+ {
1969
+ "id": "llm_output_handling",
1970
+ "remediation_advice": "Implement output filtering and validation to ensure the LLM's responses are appropriate and secure. Use context-aware controls to manage how the LLM processes and responds to various inputs. Regularly audit and update the LLM to handle new types of outputs and emerging security threats. Train users on the potential risks associated with LLM outputs, particularly in sensitive applications.",
1971
+ "references": [
1972
+ "https://whylabs.ai/blog/posts/safeguard-monitor-large-language-model-llm-applications"
1973
+ ]
1974
+ },
1975
+ {
1976
+ "id": "training_data_poisoning",
1977
+ "remediation_advice": "Implement robust anomaly detection systems to identify and address poisoned data in real-time. Regularly retrain the LLM with clean, diverse, and representative datasets to correct any potential biases or vulnerabilities. Engage in continuous monitoring and auditing of the training process and data sources.",
1978
+ "references": [
1979
+ "https://owasp.org/www-project-top-10-for-large-language-model-applications/#:~:text=,security%2C%20accuracy%2C%20or%20ethical%20behavior",
1980
+ "https://owasp.org/www-project-top-10-for-large-language-model-applications/Archive/0_1_vulns/Training_Data_Poisoning.html"
1981
+ ]
1982
+ },
1983
+ {
1984
+ "id": "excessive_agency_permission_manipulation",
1985
+ "remediation_advice": "Implement stringent access controls and define clear user permissions for interacting with the LLM. Employ regular audits and monitoring to detect and prevent unauthorized or excessive permission changes. Use role-based access control systems to manage user permissions effectively. Educate users and administrators about the risks of permission manipulation and establish protocols for safely managing access rights.",
1986
+ "references": [
1987
+ "https://owasp.org/www-project-ai-security-and-privacy-guide/#:~:text=,auditability%2C%20bias%20countermeasures%20and%20oversight"
1988
+ ]
1989
+ }
1990
+ ]
1991
+ }
1992
+ ]
1993
+ },
1994
+ {
1995
+ "id": "indicators_of_compromise",
1996
+ "remediation_advice": ""
1997
+ },
1998
+ {
1999
+ "id": "data_biases",
2000
+ "children": [
2001
+ {
2002
+ "id": "representation_bias",
2003
+ "remediation_advice": "Diversify data sources and ensure the dataset represents all relevant groups proportionally to prevent skewing model outcomes.",
2004
+ "references": [
2005
+ "https://fairmlbook.org"
2006
+ ]
2007
+ },
2008
+ {
2009
+ "id": "pre_existing_bias",
2010
+ "remediation_advice": "Identify and correct biases in the data collection phase, and review historical data for any inherent biases that could affect outcomes.",
2011
+ "references": [
2012
+ "https://ai.google/responsibilities/responsible-ai-practices/"
2013
+ ]
2014
+ }
2015
+ ]
2016
+ },
2017
+ {
2018
+ "id": "algorithmic_biases",
2019
+ "children": [
2020
+ {
2021
+ "id": "processing_bias",
2022
+ "remediation_advice": "Design algorithms to process all data fairly, implementing checks to detect and mitigate biases that arise during data processing.",
2023
+ "references": [
2024
+ "https://paperswithcode.com/task/fairness-in-ml"
2025
+ ]
2026
+ },
2027
+ {
2028
+ "id": "aggregation_bias",
2029
+ "remediation_advice": "Ensure that data aggregation methods maintain the integrity of subgroups, preventing dilution of minority data.",
2030
+ "references": [
2031
+ "https://www.microsoft.com/en-us/ai/responsible-ai-resources"
2032
+ ]
2033
+ }
2034
+ ]
2035
+ },
2036
+ {
2037
+ "id": "societal_biases",
2038
+ "children": [
2039
+ {
2040
+ "id": "confirmation_bias",
2041
+ "remediation_advice": "Promote a culture of critical thinking and questioning in analysis to avoid confirming pre-existing beliefs or hypotheses.",
2042
+ "references": [
2043
+ "https://hbr.org/2019/05/the-problem-with-confirmation-bias"
2044
+ ]
2045
+ },
2046
+ {
2047
+ "id": "systemic_bias",
2048
+ "remediation_advice": "Review and reform policies and practices that lead to unfair advantages or disadvantages for specific groups across systems.",
2049
+ "references": [
2050
+ "https://www.brookings.edu/research/how-to-combat-systemic-bias/"
2051
+ ]
2052
+ }
2053
+ ]
2054
+ },
2055
+ {
2056
+ "id": "misinterpretation_biases",
2057
+ "children": [
2058
+ {
2059
+ "id": "context_ignorance",
2060
+ "remediation_advice": "Include contextual information in the analysis and interpretation phases to avoid misinterpreting data or trends.",
2061
+ "references": [
2062
+ "https://contextualscience.org/contextualism"
2063
+ ]
2064
+ }
2065
+ ]
2066
+ },
2067
+ {
2068
+ "id": "developer_biases",
2069
+ "children": [
2070
+ {
2071
+ "id": "implicit_bias",
2072
+ "remediation_advice": "Implement training programs to raise awareness and reduce the impact of unconscious biases among developers.",
2073
+ "references": [
2074
+ "https://implicit.harvard.edu/implicit/takeatest.html"
2075
+ ]
2076
+ }
2077
+ ]
2078
+ }
2079
+ ]
2080
+ }