forked from bugcrowd/vulnerability-rating-taxonomy
-
Notifications
You must be signed in to change notification settings - Fork 0
/
remediation_advice.json
1811 lines (1811 loc) · 132 KB
/
remediation_advice.json
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
{
"metadata": {
"default": null,
"keys": ["remediation_advice", "references"]
},
"content": [
{
"id": "server_security_misconfiguration",
"references": [
"https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration",
"http://projects.webappsec.org/w/page/13246959/Server%20Misconfiguration"
],
"children": [
{
"id": "server_side_request_forgery_ssrf",
"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.",
"references": [
"https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control",
"http://projects.webappsec.org/w/page/13246913/Abuse%20of%20Functionality",
"http://resources.infosecinstitute.com/the-ssrf-vulnerability/",
"https://www.bishopfox.com/blog/2015/04/vulnerable-by-design-understanding-server-side-request-forgery/",
"http://niiconsulting.com/checkmate/2015/04/server-side-request-forgery-ssrf/"
]
},
{
"id": "unsafe_cross_origin_resource_sharing",
"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.",
"references": [
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/HTML5_Security_Cheat_Sheet.md#cross-origin-resource-sharing",
"https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS"
]
},
{
"id": "request_smuggling",
"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.",
"references": [
"https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Request_Smuggling_Prevention_Cheat_Sheet.html"
]
},
{
"id": "path_traversal",
"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).",
"references": [
"https://www.owasp.org/index.php/Path_Traversal",
"https://www.owasp.org/index.php/File_System#Path_traversal",
"http://projects.webappsec.org/w/page/13246952/Path%20Traversal"
]
},
{
"id": "directory_listing_enabled",
"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.",
"references": [
"http://projects.webappsec.org/w/page/13246922/Directory%20Indexing"
]
},
{
"id": "same_site_scripting",
"remediation_advice": "As a best practice, do not resolve targets or hostnames to 127.0.0.1 or similar addresses.",
"references": ["http://seclists.org/bugtraq/2008/Jan/270"]
},
{
"id": "ssl_attack_breach_poodle_etc",
"remediation_advice": "Disable SSL and use updated version of TLS that is not susceptible to the latest variation of the TLS attack.",
"references": [
"https://access.redhat.com/articles/1232123",
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.md",
"http://projects.webappsec.org/w/page/13246945/Insufficient%20Transport%20Layer%20Protection"
]
},
{
"id": "using_default_credentials",
"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.",
"references": [
"https://www.owasp.org/index.php/Testing_for_default_credentials_(OTG-AUTHN-002)",
"https://www.owasp.org/index.php/Configuration#Default_passwords",
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md"
]
},
{
"id": "misconfigured_dns",
"children": [
{
"id": "basic_subdomain_takeover",
"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.",
"references": [
"https://labs.detectify.com/2014/10/21/hostile-subdomain-takeover-using-herokugithubdesk-more/"
]
},
{
"id": "high_impact_subdomain_takeover",
"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.",
"references": [
"https://labs.detectify.com/2014/10/21/hostile-subdomain-takeover-using-herokugithubdesk-more/"
]
},
{
"id": "zone_transfer",
"remediation_advice": "Do not allow DNS zone transfers.",
"references": [
"https://www.sans.org/reading-room/whitepapers/dns/securing-dns-zone-transfer-868",
"https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-1999-0532"
]
},
{
"id": "missing_caa_record",
"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.",
"references": ["https://tools.ietf.org/html/rfc6844"]
}
]
},
{
"id": "mail_server_misconfiguration",
"children": [
{
"id": "no_spoofing_protection_on_email_domain",
"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.",
"references": [
"https://mxtoolbox.com/DMARCRecordGenerator.aspx",
"https://dmarc.org/2016/03/best-practices-for-email-senders/",
"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"
]
},
{
"id": "email_spoofing_to_inbox_due_to_missing_or_misconfigured_dmarc_on_email_domain",
"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.",
"references": [
"https://mxtoolbox.com/DMARCRecordGenerator.aspx",
"https://dmarc.org/2016/03/best-practices-for-email-senders/",
"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"
]
},
{
"id": "email_spoofing_to_spam_folder",
"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.",
"references": [
"https://dmarc.org/wiki/FAQ#My_mail_is_going_to_the_spam_folder_now.2C_is_DMARC_the_problem.3F",
"https://mxtoolbox.com/DMARCRecordGenerator.aspx",
"http://www.openspf.org/SPF_Record_Syntax"
]
},
{
"id": "missing_or_misconfigured_spf_and_or_dkim",
"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.",
"references": [
"http://www.openspf.org/SPF_Record_Syntax",
"http://www.openspf.org/FAQ/Common_mistakes#include"
]
},
{
"id": "email_spoofing_on_non_email_domain",
"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.",
"references": [
"https://mxtoolbox.com/DMARCRecordGenerator.aspx",
"https://dmarc.org/2016/03/best-practices-for-email-senders/",
"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"
]
}
]
},
{
"id": "dbms_misconfiguration",
"children": [
{
"id": "excessively_privileged_user_dba",
"remediation_advice": "Ensure that the current DBMS session user has the least amount of privilege necessary.",
"references": ["https://www.owasp.org/index.php/Least_privilege"]
}
]
},
{
"id": "lack_of_password_confirmation",
"children": [
{
"id": "change_email_address",
"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."
},
{
"id": "change_password",
"remediation_advice": "Use a password confirmation if the original password associated with the account is going to be changed."
},
{
"id": "delete_account",
"remediation_advice": "Use a password confirmation if there is a request to delete the account."
},
{
"id": "manage_two_fa",
"remediation_advice": "Use a password confirmation when managing 2FA settings."
}
]
},
{
"id": "no_rate_limiting_on_form",
"references": [
"https://www.owasp.org/index.php?title=OWASP_Periodic_Table_of_Vulnerabilities_-_Brute_Force_(Generic)_/_Insufficient_Anti-automation&setlang=en",
"http://projects.webappsec.org/w/page/13246938/Insufficient%20Anti-automation"
],
"children": [
{
"id": "registration",
"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."
},
{
"id": "login",
"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."
},
{
"id": "email_triggering",
"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."
},
{
"id": "sms_triggering",
"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."
},
{
"id": "change_password",
"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."
}
]
},
{
"id": "unsafe_file_upload",
"references": [
"https://www.owasp.org/index.php/Unrestricted_File_Upload",
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Protect_FileUpload_Against_Malicious_File.md"
],
"children": [
{
"id": "no_antivirus",
"remediation_advice": "As a best practice, consider using endpoint protection to check uploaded files for malware and viruses."
},
{
"id": "no_size_limit",
"remediation_advice": "Have a server-side check for the size limit of file uploads."
},
{
"id": "file_extension_filter_bypass",
"remediation_advice": "As a best practice, consider using a whitelist of accepted file extensions in order to mitigate against a bypass."
}
]
},
{
"id": "cookie_scoped_to_parent_domain",
"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.",
"references": ["https://tools.ietf.org/html/rfc6265"]
},
{
"id": "missing_secure_or_httponly_cookie_flag",
"references": [
"https://www.owasp.org/index.php/SecureFlag",
"https://www.owasp.org/index.php/HttpOnly"
],
"children": [
{
"id": "session_token",
"remediation_advice": "Set the `Secure` and `HTTPOnly` cookie flags for the session token."
},
{
"id": "non_session_cookie",
"remediation_advice": "Consider setting the `Secure` and `HTTPOnly` cookie flags for sensitive cookies."
}
]
},
{
"id": "clickjacking",
"references": [
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Clickjacking_Defense_Cheat_Sheet.md",
"https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#xfo_bp"
],
"children": [
{
"id": "sensitive_action",
"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/`."
},
{
"id": "form_input",
"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/`."
},
{
"id": "non_sensitive_action",
"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."
}
]
},
{
"id": "oauth_misconfiguration",
"children": [
{
"id": "account_takeover",
"remediation_advice": "Ensure correct implementation of OAuth protocol in order to protect client secrets and tokens, and provide secure access controls.",
"references": ["https://tools.ietf.org/html/rfc6819"]
},
{
"id": "account_squatting",
"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."
},
{
"id": "missing_state_parameter",
"remediation_advice": "The OAuth state parameter is a form of CSRF protection, ensure that it is in place and properly validated."
},
{
"id": "insecure_redirect_uri",
"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.",
"references": [
"https://www.oauth.com/oauth2-servers/redirect-uris/"
]
}
]
},
{
"id": "captcha",
"children": [
{
"id": "implementation_vulnerability",
"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."
},
{
"id": "brute_force",
"remediation_advice": "As a best practice, consider disallowing multiple attempts to guess the same CAPTCHA."
},
{
"id": "missing",
"remediation_advice": "As a best practice, consider using CAPTCHAs to prevent automated software from engaging in abusive activities on your site."
}
]
},
{
"id": "exposed_admin_portal",
"children": [
{
"id": "to_internet",
"remediation_advice": "As a best practice, consider restricting admin portal access to internal users only."
}
]
},
{
"id": "missing_dnssec",
"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.",
"references": [
"https://www.icann.org/resources/pages/dnssec-qaa-2014-01-29-en"
]
},
{
"id": "fingerprinting_banner_disclosure",
"remediation_advice": "As a best practice, do not expose the specific software version."
},
{
"id": "username_enumeration",
"children": [
{
"id": "brute_force",
"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.\"",
"references": [
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md#authentication-and-error-messages"
]
}
]
},
{
"id": "potentially_unsafe_http_method_enabled",
"references": [
"https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006)"
],
"children": [
{
"id": "options",
"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."
},
{
"id": "trace",
"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.",
"references": [
"https://www.owasp.org/index.php/Cross_Site_Tracing"
]
}
]
},
{
"id": "insecure_ssl",
"children": [
{
"id": "lack_of_forward_secrecy",
"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.",
"references": [
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.md#rule---prefer-ephemeral-key-exchanges"
]
},
{
"id": "insecure_cipher_suite",
"remediation_advice": "As a best practice, consider supporting only cipher suites that are known to be secure.",
"references": [
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.md#rule---only-support-strong-cryptographic-ciphers"
]
},
{
"id": "certificate_error",
"remediation_advice": "As a best practice, consider resolving any SSL certificate errors in order to establish trust and allow secure connections.",
"references": [
"https://cheapsslsecurity.com/blog/google-chrome-ssl-certificate-errors-troubleshoot-guide/"
]
}
]
},
{
"id": "rfd",
"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.",
"references": [
"https://www.owasp.org/index.php/Reflected_File_Download"
]
},
{
"id": "lack_of_security_headers",
"children": [
{
"id": "x_frame_options",
"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.",
"references": [
"https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#xfo_bp",
"https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options"
]
},
{
"id": "cache_control_for_a_non_sensitive_page",
"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.",
"references": [
"https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control"
]
},
{
"id": "x_xss_protection",
"remediation_advice": ""
},
{
"id": "strict_transport_security",
"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.",
"references": [
"https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#hsts",
"https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security"
]
},
{
"id": "x_content_type_options",
"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\".",
"references": [
"https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#xcto",
"https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options"
]
},
{
"id": "content_security_policy",
"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.",
"references": [
"https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#csp",
"https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy"
]
},
{
"id": "public_key_pins",
"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.",
"references": [
"https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#hpkp",
"https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Public-Key-Pins"
]
},
{
"id": "x_content_security_policy",
"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.",
"references": [
"https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#csp",
"https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy"
]
},
{
"id": "x_webkit_csp",
"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.",
"references": [
"https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#csp",
"https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy"
]
},
{
"id": "content_security_policy_report_only",
"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.",
"references": [
"https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#csp",
"https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy-Report-Only"
]
},
{
"id": "cache_control_for_a_sensitive_page",
"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."
}
]
},
{
"id": "waf_bypass",
"children": [
{
"id": "direct_server_access",
"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.",
"references": [
"https://blog.christophetd.fr/bypassing-cloudflare-using-internet-wide-scan-data/"
]
}
]
},
{
"id": "race_condition",
"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.",
"references": [
"https://lightningsecurity.io/blog/race-conditions/",
"https://blog.securitycompass.com/moving-beyond-the-owasp-top-10-part-1-race-conditions-912dccbb7c14",
"https://medium.com/in-the-weeds/fixing-a-race-condition-c8b475fbb994",
"https://blog.arkency.com/2015/09/testing-race-conditions/",
"http://www.javacreed.com/what-is-race-condition-and-how-to-prevent-it/",
"https://blog.golang.org/race-detector"
]
},
{
"id": "cache_poisoning",
"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.",
"references": [
"https://portswigger.net/blog/practical-web-cache-poisoning"
]
},
{
"id": "bitsquatting",
"remediation_advice": "As a best practice, consider registering any potential bitsquatting domain names.",
"references": ["http://dinaburg.org/bitsquatting.html"]
}
]
},
{
"id": "server_side_injection",
"remediation_advice": "Preventing injection requires keeping untrusted data separate from commands and queries.",
"references": [
"https://www.owasp.org/index.php/Top_10-2017_A1-Injection"
],
"children": [
{
"id": "ldap_injection",
"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.",
"references": [
"https://owasp.org/www-community/attacks/LDAP_Injection",
"https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html"
]
},
{
"id": "file_inclusion",
"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.",
"references": [
"http://resources.infosecinstitute.com/file-inclusion-attacks/",
"https://en.wikipedia.org/wiki/File_inclusion_vulnerability",
"https://www.cvedetails.com/vulnerability-list/opfileinc-1/file-inclusion.html"
]
},
{
"id": "remote_code_execution_rce",
"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.",
"references": [
"https://www.owasp.org/index.php/Command_Injection",
"https://www.cvedetails.com/vulnerability-list/opec-1/execute-code.html"
]
},
{
"id": "sql_injection",
"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.",
"references": [
"https://www.owasp.org/index.php/SQL_Injection",
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.md",
"http://projects.webappsec.org/SQL-Injection",
"https://www.cvedetails.com/vulnerability-list/opsqli-1/sql-injection.html"
]
},
{
"id": "xml_external_entity_injection_xxe",
"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.",
"references": [
"https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing",
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.md",
"http://projects.webappsec.org/XML-External-Entities",
"https://www.gracefulsecurity.com/xml-external-entity-injection-xxe-vulnerabilities/"
]
},
{
"id": "http_response_manipulation",
"children": [
{
"id": "response_splitting_crlf",
"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.",
"references": [
"https://www.owasp.org/index.php/CRLF_Injection",
"http://projects.webappsec.org/w/page/13246931/HTTP%20Response%20Splitting",
"https://www.cvedetails.com/vulnerability-list/ophttprs-1/http-response-splitting.html"
]
}
]
},
{
"id": "content_spoofing",
"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.",
"references": [
"http://projects.webappsec.org/w/page/13246917/Content%20Spoofing"
],
"children": [
{
"id": "iframe_injection",
"references": [
"http://resources.infosecinstitute.com/iframe-security-risk/"
]
},
{
"id": "impersonation_via_broken_link_hijacking",
"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."
},
{
"id": "external_authentication_injection",
"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.",
"references": ["https://www.exploit-db.com/papers/12898/"]
},
{
"id": "flash_based_external_authentication_injection",
"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."
},
{
"id": "html_content_injection",
"remediation_advice": "Ensure proper input validation and output encoding to prevent HTML content injection attacks and protect against potential malicious code execution."
},
{
"id": "email_html_injection",
"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.",
"references": [
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Input_Validation_Cheat_Sheet.md"
]
},
{
"id": "email_hyperlink_injection_based_on_email_provider",
"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.",
"references": [
"https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet"
]
},
{
"id": "text_injection",
"remediation_advice": "As a best practice, handle dynamic text input and use a whitelist of proper inputs."
},
{
"id": "homograph_idn_based",
"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.",
"references": [
"https://www.icann.org/news/announcement-2005-02-23-en",
"http://www.securityfocus.com/bid/12461",
"https://www.cvedetails.com/cve/CVE-2005-0238/"
]
},
{
"id": "rtlo",
"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.",
"references": [
"https://dl.packetstormsecurity.net/papers/general/righttoleften-override.pdf"
]
}
]
},
{
"id": "ssti",
"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.",
"references": [
"https://portswigger.net/kb/issues/00101080_server-side-template-injection"
]
}
]
},
{
"id": "broken_authentication_and_session_management",
"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.",
"references": [
"https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication",
"https://www.owasp.org/index.php/Broken_Authentication_and_Session_Management",
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md",
"http://projects.webappsec.org/Insufficient-Authentication",
"https://www.cvedetails.com/vulnerability-list/opgpriv-1/gain-privilege.html"
],
"children": [
{
"id": "two_fa_bypass",
"references": [
"https://www.owasp.org/index.php/Testing_Multiple_Factors_Authentication_(OWASP-AT-009)"
]
},
{
"id": "cleartext_transmission_of_session_token",
"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.",
"references": [
"https://www.owasp.org/index.php/Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003)",
"https://www.owasp.org/index.php/SecureFlag"
]
},
{
"id": "weak_login_function",
"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.",
"references": [
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md#transmit-passwords-only-over-tls-or-other-strong-transport"
]
},
{
"id": "session_fixation",
"remediation_advice": "Always regenerate the session token after the users properly authenticate.",
"references": [
"http://projects.webappsec.org/w/page/13246960/Session%20Fixation"
]
},
{
"id": "failure_to_invalidate_session",
"children": [
{
"id": "on_logout",
"remediation_advice": "Properly invalidate the session on the client and server-side when the user logs out of their session.",
"references": [
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Session_Management_Cheat_Sheet.md#manual-session-expiration"
]
},
{
"id": "permission_change",
"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."
},
{
"id": "on_logout_server_side_only",
"remediation_advice": "Properly invalidate the session on the server-side when the user logs out of their session.",
"references": [
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Session_Management_Cheat_Sheet.md#manual-session-expiration"
]
},
{
"id": "on_password_change",
"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.",
"references": [
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Session_Management_Cheat_Sheet.md#renew-the-session-id-after-any-privilege-level-change"
]
},
{
"id": "all_sessions",
"remediation_advice": "As a best practice, consider invalidating all user sessions on logout."
},
{
"id": "on_email_change",
"remediation_advice": "As a best practice, consider invalidating all sessions upon email change."
},
{
"id": "on_two_fa_activation_change",
"remediation_advice": "As a best practice, consider invalidating all sessions upon 2FA activation or change."
},
{
"id": "long_timeout",
"remediation_advice": "As a best practice, consider invalidating sessions after a shorter period of time."
}
]
},
{
"id": "concurrent_logins",
"remediation_advice": "As a best practice, consider disallowing multiple concurrent user sessions or logins."
}
]
},
{
"id": "sensitive_data_exposure",
"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.",
"references": [
"https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure",
"http://projects.webappsec.org/Information-Leakage",
"https://blog.detectify.com/2016/07/01/owasp-top-10-sensitive-data-exposure-6/",
"https://www.cvedetails.com/vulnerability-list/opginf-1/gain-information.html"
],
"children": [
{
"id": "disclosure_of_secrets",
"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."
},
{
"id": "exif_geolocation_data_not_stripped_from_uploaded_images",
"remediation_advice": "Remove all sensitive data from `EXIF` geolocation data from images after being uploaded to the server to prevent sensitive data exposure.",
"references": [
"http://resources.infosecinstitute.com/metadata-and-information-security/"
]
},
{
"id": "visible_detailed_error_page",
"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.",
"references": [
"https://www.owasp.org/index.php/Improper_Error_Handling"
]
},
{
"id": "disclosure_of_known_public_information",
"remediation_advice": "As a best practice, avoid disclosing known public information unnecessarily."
},
{
"id": "token_leakage_via_referer",
"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."
},
{
"id": "sensitive_token_in_url",
"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`."
},
{
"id": "non_sensitive_token_in_url",
"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`."
},
{
"id": "weak_password_reset_implementation",
"references": [
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Forgot_Password_Cheat_Sheet.md",
"http://projects.webappsec.org/Insufficient-Password-Recovery"
],
"children": [
{
"id": "password_reset_token_sent_over_http",
"remediation_advice": "Avoid sending a password reset token over `HTTP`. A password reset token must always be transmitted via `HTTPS`."
},
{
"id": "token_leakage_via_host_header_poisoning",
"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.",
"references": [
"https://www.acunetix.com/blog/articles/automated-detection-of-host-header-attacks/"
]
}
]
},
{
"id": "mixed_content",
"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.",
"references": [
"https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Do_Not_Mix_TLS_and_Non-TLS_Content",
"https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content"
]
},
{
"id": "sensitive_data_hardcoded",
"children": [
{
"id": "oauth_secret",
"remediation_advice": "Consider using OAuth Implicit Grant to avoid hardcoding the OAuth secret key within the application.",
"references": ["https://tools.ietf.org/html/rfc6749#section-4.2"]
}
]
},
{
"id": "xssi",
"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.",
"references": ["https://www.scip.ch/en/?labs.20160414"]
},
{
"id": "json_hijacking",
"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.",
"references": [
"http://www.thespanner.co.uk/2011/05/30/json-hijacking/"
]
},
{
"id": "via_localstorage_sessionstorage",
"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",
"references": [
"http://michael-coates.blogspot.com/2010/07/html5-local-storage-and-xss.html"
]
}
]
},
{
"id": "cross_site_scripting_xss",
"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.",
"references": [
"https://www.owasp.org/index.php/Top_10-2017_A7-Cross-Site_Scripting_(XSS)",
"https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)",
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md",
"http://projects.webappsec.org/Cross-Site+Scripting",
"https://www.cvedetails.com/vulnerability-list/opxss-1/xss.html"
],
"children": [
{
"id": "trace_method",
"remediation_advice": "As the TRACE method can be utilized to bypass certain protections, consider disabling the HTTP method TRACE.",
"references": ["https://www.owasp.org/index.php/Cross_Site_Tracing"]
}
]
},
{
"id": "broken_access_control",
"children": [
{
"id": "idor",
"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.",
"references": [
"https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References",
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.md"
]
},
{
"id": "username_enumeration",
"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.",
"references": [
"https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control",
"https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure",
"http://projects.webappsec.org/w/page/13246936/Information%20Leakage"
]
},
{
"id": "exposed_sensitive_android_intent",
"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",
"references": [
"https://www.owasp.org/index.php/Mobile_Top_10_2016-M1-Improper_Platform_Usage"
]
},
{
"id": "exposed_sensitive_ios_url_scheme",
"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.",
"references": [
"https://www.owasp.org/index.php/Mobile_Top_10_2016-M1-Improper_Platform_Usage",
"https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html"
]
}
]
},
{
"id": "cross_site_request_forgery_csrf",
"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.",
"references": [
"https://www.owasp.org/index.php/Top_10_2013-A8-Cross-Site_Request_Forgery_(CSRF)",
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md",
"http://projects.webappsec.org/w/page/13246919/Cross%20Site%20Request%20Forgery",
"https://www.cvedetails.com/vulnerability-list/opcsrf-1/csrf.html"
]
},
{
"id": "application_level_denial_of_service_dos",
"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.",
"references": [
"https://www.owasp.org/index.php/Application_Denial_of_Service",
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Denial_of_Service_Cheat_Sheet.md",
"http://projects.webappsec.org/Denial-of-Service",
"https://www.cvedetails.com/vulnerability-list/opdos-1/denial-of-service.html",
"https://www.owasp.org/images/d/da/OWASP_IL_7_Application_DOS.pdf"
]
},
{
"id": "unvalidated_redirects_and_forwards",
"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.",
"references": [
"https://www.owasp.org/index.php/Top_10_2013-A10-Unvalidated_Redirects_and_Forwards",
"https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.md",
"http://projects.webappsec.org/w/page/13246981/URL%20Redirector%20Abuse"
],
"children": [
{
"id": "tabnabbing",
"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.",
"references": [
"http://www.azarask.in/blog/post/a-new-type-of-phishing-attack/"
]
},
{
"id": "lack_of_security_speed_bump_page",
"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."
}
]
},
{
"id": "external_behavior",
"remediation_advice": "Whenever possible ensure that any security controls that help affect external appliations are in place.",
"children": [
{
"id": "browser_feature",
"children": [
{
"id": "plaintext_password_field",
"remediation_advice": "As a best practice, do not allow password fields to be shown in plain text instead of masked."
},
{
"id": "save_password",
"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."
},
{
"id": "autocomplete_enabled",
"remediation_advice": "As a best practice, do not have Autocomplete enabled by default."
},
{
"id": "autocorrect_enabled",
"remediation_advice": "Should the autocorrect feature cause unintended issues, disable autocorrect."
},
{
"id": "aggressive_offline_caching",
"remediation_advice": "Avoid caching data unnecessarily, especially sensitive information."
}
]
}
]
},
{
"id": "insufficient_security_configurability",
"references": [
"https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration"
],