diff --git a/src/main/java/com/webfuzzing/commons/faults/DefinedFaultCategory.java b/src/main/java/com/webfuzzing/commons/faults/DefinedFaultCategory.java index aa5680b..439bccf 100644 --- a/src/main/java/com/webfuzzing/commons/faults/DefinedFaultCategory.java +++ b/src/main/java/com/webfuzzing/commons/faults/DefinedFaultCategory.java @@ -10,8 +10,10 @@ public enum DefinedFaultCategory implements FaultCategory { code label are still up to discussion and re-arrangement... */ - // 1xx: Base - // might keep other 2xx,...,8xx for other groups (eg, security, GraphQL, RPC) + // 1xx: HTTP/REST + // 2xx: Schema/Robustness + // 3xx: Security + // others: currently WiP // 9xx is reserved for custom codes HTTP_STATUS_500(100, "HTTP Status 500", @@ -25,8 +27,63 @@ public enum DefinedFaultCategory implements FaultCategory { " communications with other APIs, a status code 500 could be sent." + " As such, although there is high chances that a 500 status code might point to the presence of a" + " software fault in the tested application, they still need to be manually checked due to possible 'false-positive'."), - - SCHEMA_INVALID_RESPONSE(101, "Received A Response From API With A Structure/Data That Is Not Matching Its Schema", + HTTP_STATUS_NO_NON_STANDARD_CODES(101, "HTTP Violation: no-non-standard-codes", "invalidStatusCode", + "HTTP status codes outside the range 100-599 are not valid."), + HTTP_STATUS_NO_201_IF_DELETE(102, "HTTP Violation: no-201-if-delete", "201OnDelete", + "A DELETE operation is meant to remove a resource, and so it should not states to 201 create one."), + HTTP_STATUS_NO_201_IF_GET(103, "HTTP Violation: no-201-if-get", "201OnGet", + "A GET operation is meant to retrieve a resource, and so it should not states to 201 create one."), + HTTP_STATUS_NO_201_IF_PATCH(104, "HTTP Violation: no-201-if-patch", "201OnPatch", + "A PATCH operation is meant to modify a resource, and so it should not states to 201 create one."), + HTTP_STATUS_NO_204_IF_CONTENT(105, "HTTP Violation: no-204-if-content", "204WhenContent", + "If a response contains a payload, it should not state it 204 contains none."), + HTTP_STATUS_NO_413_IF_NO_PAYLOAD(106, "HTTP Violation: no-413-if-no-payload", "413WhenNoPayload", + "Cannot state a payload is too large if there is no payload."), + HTTP_STATUS_NO_415_IF_NO_PAYLOAD(107, "HTTP Violation: no-415-if-no-payload", "415WhenNoPayload", + "Cannot state a payload is of the wrong type if there is no payload."), + HTTP_STATUS_NO_304_IF_NO_GET_OR_HEAD(108, "HTTP Violation: no-304-if-no-get-or-head", "304OnWrongVerb", + "A 304 response is not valid if the request was not either a GET or a HEAD."), + HTTP_STATUS_NO_401_IF_NO_WWW_AUTHENTICATE(109, "HTTP Violation: no-401-if-no-authenticate", "401MissingWwwAuthenticate", + "If an API responds with a 401 non-authenticated error, such response MUST contain a www-authenticate header, with the needed information." + + " In HTTP, this is not optional."), + HTTP_STATUS_NO_405_IF_NO_ALLOW(110, "HTTP Violation: no-405-if-no-allow", "405MissingAllow", + "A 405 Not Allowed response must contain an Allow header specifying what is allowed."), + HTTP_STATUS_NO_205_IF_CONTENT(111,"HTTP Violation: no-205-if-content","205WhenContent", + "If a response contains a payload, it should not return a 205, as that requires no payload."), + HTTP_STATUS_NO_426_IF_NO_UPGRADE(112,"HTTP Violation: no-426-if-no-upgrade","426MissingUpgrade", + "A 426 response must contain an Upgrade header with the needed information."), + HTTP_NONWORKING_DELETE(113,"HTTP Violation: Resource Still Accessible After Successful DELETE", "deleteDoesNotWork", + "If a resource is deleted, and the API responds that such request was successful, then such" + + " resource should no longer being available." + + " New requests to access it should fail." + + " Otherwise, if it is still possible to access the resource, then it was not really deleted." + + " Then, as such, it means that the delete operation is faulty."), + HTTP_SIDE_EFFECTS_FAILED_MODIFICATION(114, "HTTP Violation: A Failed PUT or PATCH Must Not Change The Resource", "sideEffectsFailedModification", + "Write operations that fail due to user errors should not leave side effects on the system." + + " There should not be partial updates: either all are applied, or none."), + HTTP_REPEATED_CREATE_PUT(115, "HTTP Violation: Repeated PUT Creates Resource With 201 Instead of Updating", "repeatedCreatePut", + "A PUT operation can either update (e.g., 200 or 204) or create (201) a resource." + + " If a resource is 201 created with a PUT, a second PUT should update the resource, and not be marked as recreated."), + HTTP_MISLEADING_CREATE_PUT(116, "HTTP Violation: Misleading PUT 201 Creates When Resource Already Exists", "misleadingCreatePut", + "A PUT operation can either update (e.g., 200 or 204) or create (201) a resource." + + " If a resource already exists, than a PUT operation on it would update it, and not create it."), + HTTP_PARTIAL_UPDATE_PUT(117, "HTTP Violation: The Verb PUT Must Make a Full Replacement", "partialUpdatePut", + "A PUT operation is used to make a full replacement of a resource"), + HTTP_NON_IDEMPOTENT_PUT(118, "HTTP Violation: PUT Implementation Must be Idempotent", "nonIdempotentPut", + "A PUT operation is treated as idempotent. A write operation with a PUT that is not implemented as idempotent might have severe repercussions," + + " as such operation could be automatically repeated any entity involved in the HTTP connection without any warning to the user."), + HTTP_INVALID_MERGE_PATCH(119, "HTTP Violation: Invalid JSON Merge Patch", "invalidMergePatch", + "A JSON Merge Path has a specific semantics, defining how values are modified based on the input payloads." + + " Modifying entries not specified in the payload would be a clear implementation fault."), + HTTP_INVALID_LOCATION(120, "HTTP Violation: Invalid Location HTTP Header", "returnsInvalidLocationHeader", + "Even outside of 3xx redirections, the Location header can be used to specify for example where newly created resources can be accessed." + + " However, if a Location value point to a path for which there is no valid operation (not necessarily a GET) in the API, then such value might" + + " be likely wrong."), + + + // 2xx: schema + + SCHEMA_INVALID_RESPONSE(200, "Schema Violation: Received A Response From API With A Structure/Data That Is Not Matching Its Schema", "returnsMismatchResponseWithSchema", "A schema, like for example OpenAPI for REST, defines the structures not only of the inputs but" + " also the outputs of the API." + @@ -34,8 +91,22 @@ public enum DefinedFaultCategory implements FaultCategory { " However, whether the fault is in the API (i.e., it does not conform to the schema) or in the schema" + " itself (i.e., it is underspecified, or having mistakes) is something that cannot be known for" + " sure without debugging the issue."), - - SCHEMA_VALIDATION_BYPASS(102, "Received Success Response When Sending Wrong Data", + SCHEMA_INVALID_ALLOW(201, "Schema Violation: Invalid Allow HTTP Header", "invalidAllow", + "A returned Allow header specifies what operations (e.g., GET and PATCH) are available on a resource." + + " For consistency, this needs to match what actually defined in the schema of the API, apart from special cases" + + " such as HEAD and OPTIONS."), + SCHEMA_STATUS_NO_401_IF_NO_AUTH(202, "Schema Violation: no-401-if-no-auth", "401WhenNoAuth", + "Should not return a 401 non-authenticated if there is no authentication in the definition of the API (or conversely, authentication definition" + + " is wrongly missing)."), + SCHEMA_STATUS_NO_403_IF_NO_401(203, "Schema Violation: no-403-if-no-401", "403WhenNo401", + "Should not return a 403 non-authorized if there is no 401 non-authenticated in the definition of the API (or conversely, such definition" + + " is wrongly missing)."), + SCHEMA_STATUS_HAS_406_IF_ACCEPT(204, "Schema Violation: has-406-if-accept", "406WhenValid", + "If a valid payload is sent based on what declared in the schema, it should not happen that the API responds with a 406" + + " non-valid payload type."), + SCHEMA_STATUS_NO_501_IF_IMPLEMENTED(205, "Schema Violation: no-501-if-implemented", "501OnDeclaredEndpoint", + "If a schema defines an endpoint, then a call on it should not return a 501 Non-Implemented."), + SCHEMA_VALIDATION_BYPASS(206, "Received Success Response When Sending Wrong Data", "successOnInvalidInputs", "API inputs might have constraints (e.g., integers in a specific range, and strings matching a" + " given regular expression)." + @@ -45,60 +116,40 @@ public enum DefinedFaultCategory implements FaultCategory { " However, if for any reason the request is processed successfully, then it is a fault." + " Either the schema is incorrect, or the API is not properly discarding invalid data."), - DELETE_NOT_WORKING(103, "Resource Still Accessible After Being Deleted", - "deleteNotWorking", - "If a resource is deleted, and the API responds that such request was successful, then such" + - " resource should no longer being available." + - " New requests to access it should fail." + - " Otherwise, if it is still possible to access the resource, then it was not really deleted." + - " Then, as such, it means that the delete operation is faulty."), - FAILED_CREATION_SIDE_EFFECTS(104, "Failed Creation of Resource Has Side Effects on Backend", - "sideEffectsOnFailedCreation", - "The API might expose endpoints to create new resources." + - " The creation of a new resource might fail due to non-satisfied input constraints, or based" + - " on constraints in the state of the backend." + - " If the API reports that the creation operation failed, then such action should have no side-effects" + - " The resource (e.g., with partial data) should not be accessible."), + // 3xx: security - // 2xx: security - - SQL_INJECTION(200, "SQL Injection (SQLi)", + SECURITY_SQL_INJECTION(300, "SQL Injection (SQLi)", "vulnerableToSQLInjection", "Input data was not properly sanitized." + " Its use in SQL commands led to execute arbitrary commands on the database." + " See OWASP Top 10 for more information."), - - XSS(201, "Cross-Site Scripting (XSS)", + SECURITY_XSS(301, "Cross-Site Scripting (XSS)", "vulnerableToXSS", "XSS is an attack in which it is possible to inject malicious scripts into web pages viewed users." + " This works as well in APIs, if the malicious payload is stored as it is," + " and then read afterwards by a frontend web application." + " See OWASP Top 10 for more information."), - - SSRF(202,"Server-Side Request Forgery (SSRF)", + SECURITY_SSRF(302,"Server-Side Request Forgery (SSRF)", "vulnerableToSSRF", "Some inputs might be URLs, which are then used by the API to retrieve data from external services." + " However, if the hostnames of these URLs are not verified, the API could be tricked into making requests" + " towards servers it should not to, like for example the 'localhost'." + " See OWASP Top 10 for more information."), - - MASS_ASSIGNMENT(203,"Mass Assignment", + SECURITY_MASS_ASSIGNMENT(303,"Mass Assignment", "vulnerableToMassAssignment", "This vulnerability exploits possible active record pattern misconfigurations to modify fields of " + " a record that should not be accessible via the API." + " See OWASP Top 10 for more information."), - - SECURITY_EXISTENCE_LEAKAGE(204, "Leakage Information Existence of Protected Resource", + SECURITY_EXISTENCE_LEAKAGE(304, "Leakage Information Existence of Protected Resource", "allowsUnauthorizedAccessToProtectedResource", "When accessing a protected resource, could get as a response a 403 not-authorized status code." + " If the resource does not exist, then returning a 404 would be a security leak, as now the client would" + " know if resources, they have no access to, do exist or not." + " In these cases, to avoid unauthorized information leakage, a server should consistently either always return 403" + " or 404 for protected resources, regardless of whether they exist or not."), - - SECURITY_NOT_RECOGNIZED_AUTHENTICATED(205, "Wrongly Not Recognized as Authenticated", + SECURITY_NOT_RECOGNIZED_AUTHENTICATED(305, "Wrongly Not Recognized as Authenticated", "authenticatedButWronglyToldNot", "If the user is providing valid credentials, and if they try to access a protected resource," + " they should get a status code 403 (not authorized), and not 401 (not authenticated)." + @@ -106,8 +157,7 @@ public enum DefinedFaultCategory implements FaultCategory { " have no right to access to that resource." + " However, to avoid false positives related to misconfigured credentials, these credentials should be first" + " successfully validated on some other resources before flagging a returned 401 as a server fault."), - - SECURITY_WRONG_AUTHORIZATION(206, "Allowed To Modify Resource That Likely Should Had Been Protected", + SECURITY_WRONG_AUTHORIZATION(306, "Allowed To Modify Resource That Likely Should Had Been Protected", "missedAuthorizationCheck", "BOLA and BFLA are major security vulnerabilities. To avoid users accessing protected resources," + " authorization mechanisms are usually put in place." + @@ -122,28 +172,27 @@ 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_IGNORE_ANONYMOUS(207, "A Protected Resource Is Accessible Without Providing Any Authentication", + SECURITY_IGNORE_ANONYMOUS(307, "A Protected Resource Is Accessible Without Providing Any Authentication", "ignoreAnonymous", "Protected resources would return a 403 status code when a user that has no rights to them tries" + " to access them. Without providing a formal specification, it might not be possible to know which users" + " have rights or not on a resource. However, being able to access it with no authentication, while some" + " authenticated users are blocked, would be a major security vulnerability. Blocked users could simply" + " drop their authentication credentials to access those protected resources."), - SECURITY_ANONYMOUS_MODIFICATIONS(208, "Anonymous Modifications", + SECURITY_ANONYMOUS_MODIFICATIONS(308, "Anonymous Modifications", "anonymousModifications", "Not all systems require authentication when reading data, or creating new ones." + " Without a formal specification, a fuzzer cannot know if a resource is expected to be public or not." + " However, 'modifying' data (e.g., with DELETE, PUT and PATCH) with no credentials is problematic. " + " A user could delete all existing data, or change any new data as soon as it is created by others."), - SECURITY_LEAKED_STACK_TRACES(209, "Leaked Stack Trace", + SECURITY_LEAKED_STACK_TRACES(309, "Leaked Stack Trace", "leakedStackTrace", "In case of bugs, the internal business logic of the tested application could throw exceptions." + " For debugging reasons, the responses from the HTTP server could contain the stack-trace of those" + " thrown exceptions." + " Albeit useful for debugging, those stack-traces could reveal internal details of the system." + " This would be a security leak if those debugging settings are left in production."), - SECURITY_HIDDEN_ACCESSIBLE_ENDPOINT(210, "Hidden Accessible Endpoint", + SECURITY_HIDDEN_ACCESSIBLE_ENDPOINT(310, "Hidden Accessible Endpoint", "hiddenAccessible", "To test an API, there is the need of a schema that specifies what endpoints can be called." + " Being able to call endpoints that are not declared in the schema is a potential risk, as those" + @@ -151,6 +200,9 @@ public enum DefinedFaultCategory implements FaultCategory { " protections might not be fully tested or in place." + " Either the call should fail for auth reasons (e.g., 401 and 403 in REST APIs), or the system" + " should respond that the endpoint does not exist (e.g., 405 and 501)."), + + + ; private final int code; diff --git a/src/main/resources/wfc/faults/fault_categories.json b/src/main/resources/wfc/faults/fault_categories.json index 462077b..305af84 100644 --- a/src/main/resources/wfc/faults/fault_categories.json +++ b/src/main/resources/wfc/faults/fault_categories.json @@ -6,92 +6,230 @@ "label" : "F100:HTTP Status 500" }, { "code" : 101, - "testCaseLabel" : "returnsMismatchResponseWithSchema", - "fullDescription" : "A schema, like for example OpenAPI for REST, defines the structures not only of the inputs but also the outputs of the API. If what returned by an API is not conforming to its schema, then it is a clear fault. However, whether the fault is in the API (i.e., it does not conform to the schema) or in the schema itself (i.e., it is underspecified, or having mistakes) is something that cannot be known for sure without debugging the issue.", - "descriptiveName" : "Received A Response From API With A Structure/Data That Is Not Matching Its Schema", - "label" : "F101:Received A Response From API With A Structure/Data That Is Not Matching Its Schema" + "testCaseLabel" : "invalidStatusCode", + "fullDescription" : "HTTP status codes outside the range 100-599 are not valid.", + "descriptiveName" : "HTTP Violation: no-non-standard-codes", + "label" : "F101:HTTP Violation: no-non-standard-codes" }, { "code" : 102, - "testCaseLabel" : "successOnInvalidInputs", - "fullDescription" : "API inputs might have constraints (e.g., integers in a specific range, and strings matching a given regular expression). Also, they need be to of specific types (e.g., integers, booleans, strings, dates, arrays and objects). If some input data does not satisfy the type on constraints defined in the schema, then the API should mark the request as 'user error'. However, if for any reason the request is processed successfully, then it is a fault. Either the schema is incorrect, or the API is not properly discarding invalid data.", - "descriptiveName" : "Received Success Response When Sending Wrong Data", - "label" : "F102:Received Success Response When Sending Wrong Data" + "testCaseLabel" : "201OnDelete", + "fullDescription" : "A DELETE operation is meant to remove a resource, and so it should not states to 201 create one.", + "descriptiveName" : "HTTP Violation: no-201-if-delete", + "label" : "F102:HTTP Violation: no-201-if-delete" }, { "code" : 103, - "testCaseLabel" : "deleteNotWorking", - "fullDescription" : "If a resource is deleted, and the API responds that such request was successful, then such resource should no longer being available. New requests to access it should fail. Otherwise, if it is still possible to access the resource, then it was not really deleted. Then, as such, it means that the delete operation is faulty.", - "descriptiveName" : "Resource Still Accessible After Being Deleted", - "label" : "F103:Resource Still Accessible After Being Deleted" + "testCaseLabel" : "201OnGet", + "fullDescription" : "A GET operation is meant to retrieve a resource, and so it should not states to 201 create one.", + "descriptiveName" : "HTTP Violation: no-201-if-get", + "label" : "F103:HTTP Violation: no-201-if-get" }, { "code" : 104, - "testCaseLabel" : "sideEffectsOnFailedCreation", - "fullDescription" : "The API might expose endpoints to create new resources. The creation of a new resource might fail due to non-satisfied input constraints, or based on constraints in the state of the backend. If the API reports that the creation operation failed, then such action should have no side-effects The resource (e.g., with partial data) should not be accessible.", - "descriptiveName" : "Failed Creation of Resource Has Side Effects on Backend", - "label" : "F104:Failed Creation of Resource Has Side Effects on Backend" + "testCaseLabel" : "201OnPatch", + "fullDescription" : "A PATCH operation is meant to modify a resource, and so it should not states to 201 create one.", + "descriptiveName" : "HTTP Violation: no-201-if-patch", + "label" : "F104:HTTP Violation: no-201-if-patch" +}, { + "code" : 105, + "testCaseLabel" : "204WhenContent", + "fullDescription" : "If a response contains a payload, it should not state it 204 contains none.", + "descriptiveName" : "HTTP Violation: no-204-if-content", + "label" : "F105:HTTP Violation: no-204-if-content" +}, { + "code" : 106, + "testCaseLabel" : "413WhenNoPayload", + "fullDescription" : "Cannot state a payload is too large if there is no payload.", + "descriptiveName" : "HTTP Violation: no-413-if-no-payload", + "label" : "F106:HTTP Violation: no-413-if-no-payload" +}, { + "code" : 107, + "testCaseLabel" : "415WhenNoPayload", + "fullDescription" : "Cannot state a payload is of the wrong type if there is no payload.", + "descriptiveName" : "HTTP Violation: no-415-if-no-payload", + "label" : "F107:HTTP Violation: no-415-if-no-payload" +}, { + "code" : 108, + "testCaseLabel" : "304OnWrongVerb", + "fullDescription" : "A 304 response is not valid if the request was not either a GET or a HEAD.", + "descriptiveName" : "HTTP Violation: no-304-if-no-get-or-head", + "label" : "F108:HTTP Violation: no-304-if-no-get-or-head" +}, { + "code" : 109, + "testCaseLabel" : "401MissingWwwAuthenticate", + "fullDescription" : "If an API responds with a 401 non-authenticated error, such response MUST contain a www-authenticate header, with the needed information. In HTTP, this is not optional.", + "descriptiveName" : "HTTP Violation: no-401-if-no-authenticate", + "label" : "F109:HTTP Violation: no-401-if-no-authenticate" +}, { + "code" : 110, + "testCaseLabel" : "405MissingAllow", + "fullDescription" : "A 405 Not Allowed response must contain an Allow header specifying what is allowed.", + "descriptiveName" : "HTTP Violation: no-405-if-no-allow", + "label" : "F110:HTTP Violation: no-405-if-no-allow" +}, { + "code" : 111, + "testCaseLabel" : "205WhenContent", + "fullDescription" : "If a response contains a payload, it should not return a 205, as that requires no payload.", + "descriptiveName" : "HTTP Violation: no-205-if-content", + "label" : "F111:HTTP Violation: no-205-if-content" +}, { + "code" : 112, + "testCaseLabel" : "426MissingUpgrade", + "fullDescription" : "A 426 response must contain an Upgrade header with the needed information.", + "descriptiveName" : "HTTP Violation: no-426-if-no-upgrade", + "label" : "F112:HTTP Violation: no-426-if-no-upgrade" +}, { + "code" : 113, + "testCaseLabel" : "deleteDoesNotWork", + "fullDescription" : "If a resource is deleted, and the API responds that such request was successful, then such resource should no longer being available. New requests to access it should fail. Otherwise, if it is still possible to access the resource, then it was not really deleted. Then, as such, it means that the delete operation is faulty.", + "descriptiveName" : "HTTP Violation: Resource Still Accessible After Successful DELETE", + "label" : "F113:HTTP Violation: Resource Still Accessible After Successful DELETE" +}, { + "code" : 114, + "testCaseLabel" : "sideEffectsFailedModification", + "fullDescription" : "Write operations that fail due to user errors should not leave side effects on the system. There should not be partial updates: either all are applied, or none.", + "descriptiveName" : "HTTP Violation: A Failed PUT or PATCH Must Not Change The Resource", + "label" : "F114:HTTP Violation: A Failed PUT or PATCH Must Not Change The Resource" +}, { + "code" : 115, + "testCaseLabel" : "repeatedCreatePut", + "fullDescription" : "A PUT operation can either update (e.g., 200 or 204) or create (201) a resource. If a resource is 201 created with a PUT, a second PUT should update the resource, and not be marked as recreated.", + "descriptiveName" : "HTTP Violation: Repeated PUT Creates Resource With 201 Instead of Updating", + "label" : "F115:HTTP Violation: Repeated PUT Creates Resource With 201 Instead of Updating" +}, { + "code" : 116, + "testCaseLabel" : "misleadingCreatePut", + "fullDescription" : "A PUT operation can either update (e.g., 200 or 204) or create (201) a resource. If a resource already exists, than a PUT operation on it would update it, and not create it.", + "descriptiveName" : "HTTP Violation: Misleading PUT 201 Creates When Resource Already Exists", + "label" : "F116:HTTP Violation: Misleading PUT 201 Creates When Resource Already Exists" +}, { + "code" : 117, + "testCaseLabel" : "partialUpdatePut", + "fullDescription" : "A PUT operation is used to make a full replacement of a resource", + "descriptiveName" : "HTTP Violation: The Verb PUT Must Make a Full Replacement", + "label" : "F117:HTTP Violation: The Verb PUT Must Make a Full Replacement" +}, { + "code" : 118, + "testCaseLabel" : "nonIdempotentPut", + "fullDescription" : "A PUT operation is treated as idempotent. A write operation with a PUT that is not implemented as idempotent might have severe repercussions, as such operation could be automatically repeated any entity involved in the HTTP connection without any warning to the user.", + "descriptiveName" : "HTTP Violation: PUT Implementation Must be Idempotent", + "label" : "F118:HTTP Violation: PUT Implementation Must be Idempotent" +}, { + "code" : 119, + "testCaseLabel" : "invalidMergePatch", + "fullDescription" : "A JSON Merge Path has a specific semantics, defining how values are modified based on the input payloads. Modifying entries not specified in the payload would be a clear implementation fault.", + "descriptiveName" : "HTTP Violation: Invalid JSON Merge Patch", + "label" : "F119:HTTP Violation: Invalid JSON Merge Patch" +}, { + "code" : 120, + "testCaseLabel" : "returnsInvalidLocationHeader", + "fullDescription" : "Even outside of 3xx redirections, the Location header can be used to specify for example where newly created resources can be accessed. However, if a Location value point to a path for which there is no valid operation (not necessarily a GET) in the API, then such value might be likely wrong.", + "descriptiveName" : "HTTP Violation: Invalid Location HTTP Header", + "label" : "F120:HTTP Violation: Invalid Location HTTP Header" }, { "code" : 200, + "testCaseLabel" : "returnsMismatchResponseWithSchema", + "fullDescription" : "A schema, like for example OpenAPI for REST, defines the structures not only of the inputs but also the outputs of the API. If what returned by an API is not conforming to its schema, then it is a clear fault. However, whether the fault is in the API (i.e., it does not conform to the schema) or in the schema itself (i.e., it is underspecified, or having mistakes) is something that cannot be known for sure without debugging the issue.", + "descriptiveName" : "Schema Violation: Received A Response From API With A Structure/Data That Is Not Matching Its Schema", + "label" : "F200:Schema Violation: Received A Response From API With A Structure/Data That Is Not Matching Its Schema" +}, { + "code" : 201, + "testCaseLabel" : "invalidAllow", + "fullDescription" : "A returned Allow header specifies what operations (e.g., GET and PATCH) are available on a resource. For consistency, this needs to match what actually defined in the schema of the API, apart from special cases such as HEAD and OPTIONS.", + "descriptiveName" : "Schema Violation: Invalid Allow HTTP Header", + "label" : "F201:Schema Violation: Invalid Allow HTTP Header" +}, { + "code" : 202, + "testCaseLabel" : "401WhenNoAuth", + "fullDescription" : "Should not return a 401 non-authenticated if there is no authentication in the definition of the API (or conversely, authentication definition is wrongly missing).", + "descriptiveName" : "Schema Violation: no-401-if-no-auth", + "label" : "F202:Schema Violation: no-401-if-no-auth" +}, { + "code" : 203, + "testCaseLabel" : "403WhenNo401", + "fullDescription" : "Should not return a 403 non-authorized if there is no 401 non-authenticated in the definition of the API (or conversely, such definition is wrongly missing).", + "descriptiveName" : "Schema Violation: no-403-if-no-401", + "label" : "F203:Schema Violation: no-403-if-no-401" +}, { + "code" : 204, + "testCaseLabel" : "406WhenValid", + "fullDescription" : "If a valid payload is sent based on what declared in the schema, it should not happen that the API responds with a 406 non-valid payload type.", + "descriptiveName" : "Schema Violation: has-406-if-accept", + "label" : "F204:Schema Violation: has-406-if-accept" +}, { + "code" : 205, + "testCaseLabel" : "501OnDeclaredEndpoint", + "fullDescription" : "If a schema defines an endpoint, then a call on it should not return a 501 Non-Implemented.", + "descriptiveName" : "Schema Violation: no-501-if-implemented", + "label" : "F205:Schema Violation: no-501-if-implemented" +}, { + "code" : 206, + "testCaseLabel" : "successOnInvalidInputs", + "fullDescription" : "API inputs might have constraints (e.g., integers in a specific range, and strings matching a given regular expression). Also, they need be to of specific types (e.g., integers, booleans, strings, dates, arrays and objects). If some input data does not satisfy the type on constraints defined in the schema, then the API should mark the request as 'user error'. However, if for any reason the request is processed successfully, then it is a fault. Either the schema is incorrect, or the API is not properly discarding invalid data.", + "descriptiveName" : "Received Success Response When Sending Wrong Data", + "label" : "F206:Received Success Response When Sending Wrong Data" +}, { + "code" : 300, "testCaseLabel" : "vulnerableToSQLInjection", "fullDescription" : "Input data was not properly sanitized. Its use in SQL commands led to execute arbitrary commands on the database. See OWASP Top 10 for more information.", "descriptiveName" : "SQL Injection (SQLi)", - "label" : "F200:SQL Injection (SQLi)" + "label" : "F300:SQL Injection (SQLi)" }, { - "code" : 201, + "code" : 301, "testCaseLabel" : "vulnerableToXSS", "fullDescription" : "XSS is an attack in which it is possible to inject malicious scripts into web pages viewed users. This works as well in APIs, if the malicious payload is stored as it is, and then read afterwards by a frontend web application. See OWASP Top 10 for more information.", "descriptiveName" : "Cross-Site Scripting (XSS)", - "label" : "F201:Cross-Site Scripting (XSS)" + "label" : "F301:Cross-Site Scripting (XSS)" }, { - "code" : 202, + "code" : 302, "testCaseLabel" : "vulnerableToSSRF", "fullDescription" : "Some inputs might be URLs, which are then used by the API to retrieve data from external services. However, if the hostnames of these URLs are not verified, the API could be tricked into making requests towards servers it should not to, like for example the 'localhost'. See OWASP Top 10 for more information.", "descriptiveName" : "Server-Side Request Forgery (SSRF)", - "label" : "F202:Server-Side Request Forgery (SSRF)" + "label" : "F302:Server-Side Request Forgery (SSRF)" }, { - "code" : 203, + "code" : 303, "testCaseLabel" : "vulnerableToMassAssignment", "fullDescription" : "This vulnerability exploits possible active record pattern misconfigurations to modify fields of a record that should not be accessible via the API. See OWASP Top 10 for more information.", "descriptiveName" : "Mass Assignment", - "label" : "F203:Mass Assignment" + "label" : "F303:Mass Assignment" }, { - "code" : 204, + "code" : 304, "testCaseLabel" : "allowsUnauthorizedAccessToProtectedResource", "fullDescription" : "When accessing a protected resource, could get as a response a 403 not-authorized status code. If the resource does not exist, then returning a 404 would be a security leak, as now the client would know if resources, they have no access to, do exist or not. In these cases, to avoid unauthorized information leakage, a server should consistently either always return 403 or 404 for protected resources, regardless of whether they exist or not.", "descriptiveName" : "Leakage Information Existence of Protected Resource", - "label" : "F204:Leakage Information Existence of Protected Resource" + "label" : "F304:Leakage Information Existence of Protected Resource" }, { - "code" : 205, + "code" : 305, "testCaseLabel" : "authenticatedButWronglyToldNot", "fullDescription" : "If the user is providing valid credentials, and if they try to access a protected resource, they should get a status code 403 (not authorized), and not 401 (not authenticated). With a 401, the user might wrongly think there is a problem with their credentials, and not that they have no right to access to that resource. However, to avoid false positives related to misconfigured credentials, these credentials should be first successfully validated on some other resources before flagging a returned 401 as a server fault.", "descriptiveName" : "Wrongly Not Recognized as Authenticated", - "label" : "F205:Wrongly Not Recognized as Authenticated" + "label" : "F305:Wrongly Not Recognized as Authenticated" }, { - "code" : 206, + "code" : 306, "testCaseLabel" : "missedAuthorizationCheck", "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" + "label" : "F306:Allowed To Modify Resource That Likely Should Had Been Protected" }, { - "code" : 207, + "code" : 307, "testCaseLabel" : "ignoreAnonymous", "fullDescription" : "Protected resources would return a 403 status code when a user that has no rights to them tries to access them. Without providing a formal specification, it might not be possible to know which users have rights or not on a resource. However, being able to access it with no authentication, while some authenticated users are blocked, would be a major security vulnerability. Blocked users could simply drop their authentication credentials to access those protected resources.", "descriptiveName" : "A Protected Resource Is Accessible Without Providing Any Authentication", - "label" : "F207:A Protected Resource Is Accessible Without Providing Any Authentication" + "label" : "F307:A Protected Resource Is Accessible Without Providing Any Authentication" }, { - "code" : 208, + "code" : 308, "testCaseLabel" : "anonymousModifications", "fullDescription" : "Not all systems require authentication when reading data, or creating new ones. Without a formal specification, a fuzzer cannot know if a resource is expected to be public or not. However, 'modifying' data (e.g., with DELETE, PUT and PATCH) with no credentials is problematic. A user could delete all existing data, or change any new data as soon as it is created by others.", "descriptiveName" : "Anonymous Modifications", - "label" : "F208:Anonymous Modifications" + "label" : "F308:Anonymous Modifications" }, { - "code" : 209, + "code" : 309, "testCaseLabel" : "leakedStackTrace", "fullDescription" : "In case of bugs, the internal business logic of the tested application could throw exceptions. For debugging reasons, the responses from the HTTP server could contain the stack-trace of those thrown exceptions. Albeit useful for debugging, those stack-traces could reveal internal details of the system. This would be a security leak if those debugging settings are left in production.", "descriptiveName" : "Leaked Stack Trace", - "label" : "F209:Leaked Stack Trace" + "label" : "F309:Leaked Stack Trace" }, { - "code" : 210, + "code" : 310, "testCaseLabel" : "hiddenAccessible", "fullDescription" : "To test an API, there is the need of a schema that specifies what endpoints can be called. Being able to call endpoints that are not declared in the schema is a potential risk, as those might be either forgotten endpoints, work-in-progress, admin-only endpoints, etc., whose security protections might not be fully tested or in place. Either the call should fail for auth reasons (e.g., 401 and 403 in REST APIs), or the system should respond that the endpoint does not exist (e.g., 405 and 501).", "descriptiveName" : "Hidden Accessible Endpoint", - "label" : "F210:Hidden Accessible Endpoint" + "label" : "F310:Hidden Accessible Endpoint" } ] \ No newline at end of file diff --git a/web-report/src/components/StatusCodeModal.tsx b/web-report/src/components/StatusCodeModal.tsx index a96e119..75f2a1d 100644 --- a/web-report/src/components/StatusCodeModal.tsx +++ b/web-report/src/components/StatusCodeModal.tsx @@ -54,8 +54,10 @@ export function StatusCodeModal({ isOpen, onClose, statusCode }: StatusCodeModal const getCategoryName = (category: number): string => { switch (category) { case 100: - return "REST/HTTP Faults" + return "HTTP Faults" case 200: + return "Schema Faults" + case 300: return "Security Faults" case 900: return "Custom Faults" @@ -70,6 +72,8 @@ export function StatusCodeModal({ isOpen, onClose, statusCode }: StatusCodeModal return "1xx" case 200: return "2xx" + case 300: + return "3xx" case 900: return "9xx" default: