Merge pull request #16 from WebFuzzing/forgotten-authentication-category

Defining forgotten authentication

Author: arcuri82

src/main/java/com/webfuzzing/commons/faults/DefinedFaultCategory.java

@@ -122,7 +122,17 @@ public enum DefinedFaultCategory implements FaultCategory {
                     " Still, some heuristics could be used to flag highly suspicious cases." +
                     " For example, if a user is blocked with a 403 to do a PUT and a PATCH on a resource, it would" +
                     " be quite suspicious if a DELETE would work just fine on that resource."),
-
+    SECURITY_FORGOTTEN_AUTHENTICATION(207, "A Protected Resource Is Accessible Without Providing Any Authentication",
+            "forgottenAuthentication",
+            "Endpoints that require authentication must never succeed without it. If the same verb and path return 401/403 " +
+                    "when invalid credentials are used, this shows the endpoint is meant to be protected. But if a call to " +
+                    "the same endpoint with no authentication at all still returns 2xx, this is a forgotten authentication bug. " +
+                    "It means a resource that should be locked is accessible anonymously, exposing or modifying data without any " +
+                    "identity checks. " +
+                    "Detection relies on identifying endpoints that demonstrate protection (i.e., return 401/403 when accessed with " +
+                    "invalid credentials), and then verifying whether the same request, when executed without any authentication, " +
+                    "still results in a successful 2xx response. If this occurs, it reveals a critical lapse in the authentication " +
+                    "mechanism.")
     ;
 
     private final int code;

src/main/resources/wfc/faults/fault_categories.json

@@ -70,4 +70,10 @@
   "fullDescription" : "BOLA and BFLA are major security vulnerabilities. To avoid users accessing protected resources, authorization mechanisms are usually put in place. However, it can happen that, on some endpoints, these authorization mechanisms are missing or misconfigured by mistake. This can have disastrous consequences, e.g., a regular user deleting all data from all other users. However, access policies could be arbitrarily complex, where some users might validly interact with some resources of other users. A common example is 'administrator' users. Without a formal specification describing in details the access policies in place, it is hard to say automatically if we are in the case of a BOLA/BFLA vulnerability. Still, some heuristics could be used to flag highly suspicious cases. For example, if a user is blocked with a 403 to do a PUT and a PATCH on a resource, it would be quite suspicious if a DELETE would work just fine on that resource.",
   "descriptiveName" : "Allowed To Modify Resource That Likely Should Had Been Protected",
   "label" : "F206:Allowed To Modify Resource That Likely Should Had Been Protected"
+}, {
+  "code" : 207,
+  "testCaseLabel" : "forgottenAuthentication",
+  "fullDescription" : "Endpoints that require authentication must never succeed without it. If the same verb and path return 401/403 when invalid credentials are used, this shows the endpoint is meant to be protected. But if a call to the same endpoint with no authentication at all still returns 2xx, this is a forgotten authentication bug. It means a resource that should be locked is accessible anonymously, exposing or modifying data without any identity checks. Detection relies on identifying endpoints that demonstrate protection (i.e., return 401/403 when accessed with invalid credentials), and then verifying whether the same request, when executed without any authentication, still results in a successful 2xx response. If this occurs, it reveals a critical lapse in the authentication mechanism.",
+  "descriptiveName" : "A Protected Resource Is Accessible Without Providing Any Authentication",
+  "label" : "F207:A Protected Resource Is Accessible Without Providing Any Authentication"
 } ]