asdasd

[Riccardo-ten-Cate]

sadas

[skf-integration[bot]]

{"items": [{"kb_item_id": null, "kb_item_title": null, "kb_items_content": null, "checklist_items_id": 1, "checklist_items_checklistID": "2.0", "checklist_items_content": "Authentication Verification Requirements", "checklist_items_type": 1, "include_always": "False", "question_ID": 0, "questions": null}, {"kb_item_id": "59", "kb_item_title": "Does The application enforce the use of secure passwords", "kb_items_content": " Description:\n\nApplications should encourage the use of strong passwords and passphrases. Preferably the\npassword policy should not put limitations or restrictions on the chosen passwords (for example\nthe length of a password). Whenever the application supports strong passwords and\nthe use of password managers, the possibility for an attacker performing a succesfull bruteforce \nattack drops significantly.\nThis also increases the possibility that the application can be used with users' passwords managers.\n\n Solution:\n\nVerify password entry fields allow, or encourage, the use of passphrases, and do not prevent\npassword managers, long passphrases or highly complex passwords being entered. \nA password ideally should be:\n at least 12 characters in length\n passwords even longer than 64 characters are allowed\n every special characters from Unicode charset should be permitted (including emoki, kanji, multiple whitespaces, ecc.)\n No limit for the number of characters allowed from the same type (lowercase characters, uppercase characters, digits, symbols) \n", "checklist_items_id": 2, "checklist_items_checklistID": "2.1.1", "checklist_items_content": "Verify that user set passwords are at least 12 characters in length. (C6)", "checklist_items_type": 1, "include_always": "False", "question_ID": 0, "questions": null}, {"kb_item_id": "59", "kb_item_title": "Does The application enforce the use of secure passwords", "kb_items_content": " Description:\n\nApplications should encourage the use of strong passwords and passphrases. Preferably the\npassword policy should not put limitations or restrictions on the chosen passwords (for example\nthe length of a password). Whenever the application supports strong passwords and\nthe use of password managers, the possibility for an attacker performing a succesfull bruteforce \nattack drops significantly.\nThis also increases the possibility that the application can be used with users' passwords managers.\n\n Solution:\n\nVerify password entry fields allow, or encourage, the use of passphrases, and do not prevent\npassword managers, long passphrases or highly complex passwords being entered. \nA password ideally should be:\n at least 12 characters in length\n passwords even longer than 64 characters are allowed\n every special characters from Unicode charset should be permitted (including emoki, kanji, multiple whitespaces, ecc.)\n No limit for the number of characters allowed from the same type (lowercase characters, uppercase characters, digits, symbols) \n", "checklist_items_id": 3, "checklist_items_checklistID": "2.1.2", "checklist_items_content": "Verify that passwords 64 characters or longer are permitted. (C6)", "checklist_items_type": 1, "include_always": "False", "question_ID": 31, "questions": "Does the sprint introduce change/affect on password policies?"}, {"kb_item_id": "59", "kb_item_title": "Does The application enforce the use of secure passwords", "kb_items_content": " Description:\n\nApplications should encourage the use of strong passwords and passphrases. Preferably the\npassword policy should not put limitations or restrictions on the chosen passwords (for example\nthe length of a password). Whenever the application supports strong passwords and\nthe use of password managers, the possibility for an attacker performing a succesfull bruteforce \nattack drops significantly.\nThis also increases the possibility that the application can be used with users' passwords managers.\n\n Solution:\n\nVerify password entry fields allow, or encourage, the use of passphrases, and do not prevent\npassword managers, long passphrases or highly complex passwords being entered. \nA password ideally should be:\n at least 12 characters in length\n passwords even longer than 64 characters are allowed\n every special characters from Unicode charset should be permitted (including emoki, kanji, multiple whitespaces, ecc.)\n No limit for the number of characters allowed from the same type (lowercase characters, uppercase characters, digits, symbols) \n", "checklist_items_id": 4, "checklist_items_checklistID": "2.1.3", "checklist_items_content": "Verify that passwords can contain spaces and truncation is not performed. Consecutive multiple spaces MAY optionally be coalesced. (C6)", "checklist_items_type": 1, "include_always": "False", "question_ID": 31, "questions": "Does the sprint introduce change/affect on password policies?"}, {"kb_item_id": "59", "kb_item_title": "Does The application enforce the use of secure passwords", "kb_items_content": " Description:\n\nApplications should encourage the use of strong passwords and passphrases. Preferably the\npassword policy should not put limitations or restrictions on the chosen passwords (for example\nthe length of a password). Whenever the application supports strong passwords and\nthe use of password managers, the possibility for an attacker performing a succesfull bruteforce \nattack drops significantly.\nThis also increases the possibility that the application can be used with users' passwords managers.\n\n Solution:\n\nVerify password entry fields allow, or encourage, the use of passphrases, and do not prevent\npassword managers, long passphrases or highly complex passwords being entered. \nA password ideally should be:\n at least 12 characters in length\n passwords even longer than 64 characters are allowed\n every special characters from Unicode charset should be permitted (including emoki, kanji, multiple whitespaces, ecc.)\n No limit for the number of characters allowed from the same type (lowercase characters, uppercase characters, digits, symbols) \n", "checklist_items_id": 5, "checklist_items_checklistID": "2.1.4", "checklist_items_content": "Verify that Unicode characters are permitted in passwords. A single Unicode code point is considered a character, so 12 emoji or 64 kanji characters should be valid and permitted.", "checklist_items_type": 1, "include_always": "False", "question_ID": 31, "questions": "Does the sprint introduce change/affect on password policies?"}, {"kb_item_id": "1343", "kb_item_title": "Permit Password Change", "kb_items_content": "Description:\n\nUsers should be able to update their password whenever it is necessary. For example, take in consideration the scenario in which they tend to use the same password for multiple purposes. If this password is leaked, the users have to immediately update their credentials in every application they are registered. Therefore, if the application does not provide an accessible password update functionality to a user, there is the risk that his account may be taken over.\n\nSolution:\n\nApplications should provide to the user a functionality that permits the change of its own password.\n", "checklist_items_id": 6, "checklist_items_checklistID": "2.1.5", "checklist_items_content": "Verify users can change their password.", "checklist_items_type": 1, "include_always": "False", "question_ID": 31, "questions": "Does the sprint introduce change/affect on password policies?"}, {"kb_item_id": "32", "kb_item_title": "Unauthorized credential changes", "kb_items_content": " Description:\n\nAn application which offers user login functionality, usually has an administration page\nwhere userdata can be modified. When the user wants to change this data he should\nspecify his current password.\n\n Solution:\n\nWhen changing user credentials or email address the user must always enter a valid\npassword in order to implement the changes. This is also called reauthentication or\nstepup / adaptive authentication. Whenever a user \"reauthenticates\" himself the current\nsession ID value should also be refreshed in order to fend oFf so called \"session hijackers\"\n", "checklist_items_id": 7, "checklist_items_checklistID": "2.1.6", "checklist_items_content": "Verify that password change functionality requires the user's current and new password.", "checklist_items_type": 1, "include_always": "False", "question_ID": 31, "questions": "Does the sprint introduce change/affect on password policies?"}, {"kb_item_id": "1345", "kb_item_title": "Verify Breached Passwords", "kb_items_content": " Description:\n\nMultiple database of leaked credentials have been released during breaches over the years. If users choose passwords already leaked, they are vulnerable to dictionary attacks.\n\n Solution:\n\nVerify that passwords submitted during account registration, login, and password change are checked against a set of breached passwords. In case the password chosen has already been breached, the application must require the user to reenter a nonbreached password.\n", "checklist_items_id": 8, "checklist_items_checklistID": "2.1.7", "checklist_items_content": "Verify that passwords submitted during account registration, login, and password change are checked against a set of breached passwords either locally (such as the top 1,000 or 10,000 most common passwords which match the system's password policy) or using an external API. If using an API a zero knowledge proof or other mechanism should be used to ensure that the plain text password is not sent or used in verifying the breach status of the password. If the password is breached, the application must require the user to set a new non-breached password. (C6)", "checklist_items_type": 1, "include_always": "False", "question_ID": 31, "questions": "Does the sprint introduce change/affect on password policies?"}, {"kb_item_id": "1344", "kb_item_title": "Provide Password Strength Checker", "kb_items_content": " Description:\n\nUsers may tend to choose easy guessable passwords. Therefore, it is suggested to implement a functionality that encourage them to set password of higher complexity.\n\n Solution:\n\nApplications should provide the users a password security meter in occasion of account registration and password change.\n", "checklist_items_id": 9, "checklist_items_checklistID": "2.1.8", "checklist_items_content": "Verify that a password strength meter is provided to help users set a stronger password.", "checklist_items_type": 1, "include_always": "False", "question_ID": 31, "questions": "Does the sprint introduce change/affect on password policies?"}, {"kb_item_id": "59", "kb_item_title": "Does The application enforce the use of secure passwords", "kb_items_content": " Description:\n\nApplications should encourage the use of strong passwords and passphrases. Preferably the\npassword policy should not put limitations or restrictions on the chosen passwords (for example\nthe length of a password). Whenever the application supports strong passwords and\nthe use of password managers, the possibility for an attacker performing a succesfull bruteforce \nattack drops significantly.\nThis also increases the possibility that the application can be used with users' passwords managers.\n\n Solution:\n\nVerify password entry fields allow, or encourage, the use of passphrases, and do not prevent\npassword managers, long passphrases or highly complex passwords being entered. \nA password ideally should be:\n at least 12 characters in length\n passwords even longer than 64 characters are allowed\n every special characters from Unicode charset should be permitted (including emoki, kanji, multiple whitespaces, ecc.)\n No limit for the number of characters allowed from the same type (lowercase characters, uppercase characters, digits, symbols) \n", "checklist_items_id": 10, "checklist_items_checklistID": "2.1.9", "checklist_items_content": "Verify that there are no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters. (C6)", "checklist_items_type": 1, "include_always": "False", "question_ID": 31, "questions": "Does the sprint introduce change/affect on password policies?"}, {"kb_item_id": "295", "kb_item_title": "no password rotation policy", "kb_items_content": "Description:\nSome policies require users to change passwords periodically, often every 90 or 180 days. \nThe benefit of password expiration, however, is debatable. Systems that implement such \npolicies sometimes prevent users from picking a password too close to a previous selection.\n\nThis policy can often backfire. Some users find it hard to devise \"good\" passwords that are \nalso easy to remember, so if people are required to choose many passwords because they have \nto change them often, they end up using much weaker passwords; the policy also encourages \nusers to write passwords down. Also, if the policy prevents a user from repeating a recent password, \nthis requires that there is a database in existence of everyone's recent passwords (or their hashes) \ninstead of having the old ones erased from memory. Finally, users may change their password repeatedly\nwithin a few minutes, and then change back to the one they really want to use, circumventing the \npassword change policy altogether.\n\nSolution:\nOnly force users to update their passwords when the password strength that is enforced by the application\nis no longer sufficient to withstand brute force attacks due to increase of computing power.\n", "checklist_items_id": 11, "checklist_items_checklistID": "2.1.10", "checklist_items_content": "Verify that there are no periodic credential rotation or password history requirements.", "checklist_items_type": 1, "include_always": "False", "question_ID": 31, "questions": "Does the sprint introduce change/affect on password policies?"}, {"kb_item_id": "59", "kb_item_title": "Does The application enforce the use of secure passwords", "kb_items_content": " Description:\n\nApplications should encourage the use of strong passwords and passphrases. Preferably the\npassword policy should not put limitations or restrictions on the chosen passwords (for example\nthe length of a password). Whenever the application supports strong passwords and\nthe use of password managers, the possibility for an attacker performing a succesfull bruteforce \nattack drops significantly.\nThis also increases the possibility that the application can be used with users' passwords managers.\n\n Solution:\n\nVerify password entry fields allow, or encourage, the use of passphrases, and do not prevent\npassword managers, long passphrases or highly complex passwords being entered. \nA password ideally should be:\n at least 12 characters in length\n passwords even longer than 64 characters are allowed\n every special characters from Unicode charset should be permitted (including emoki, kanji, multiple whitespaces, ecc.)\n No limit for the number of characters allowed from the same type (lowercase characters, uppercase characters, digits, symbols) \n", "checklist_items_id": 12, "checklist_items_checklistID": "2.1.11", "checklist_items_content": "Verify that \"paste\" functionality, browser password helpers, and external password managers are permitted.", "checklist_items_type": 1, "include_always": "False", "question_ID": 31, "questions": "Does the sprint introduce change/affect on password policies?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 13, "checklist_items_checklistID": "2.1.12", "checklist_items_content": "Verify that the user can choose to either temporarily view the entire masked password, or temporarily view the last typed character of the password on platforms that do not have this as native functionality.", "checklist_items_type": 1, "include_always": "False", "question_ID": 31, "questions": "Does the sprint introduce change/affect on password policies?"}, {"kb_item_id": "29", "kb_item_title": "Brute force password guessing", "kb_items_content": " Description:\n\nLogin functions should not be abused in an automated way that an attacker could create a\nscript that contains a list of usernames and passwords, which he could use against your\nlogin function in order to gain unauthorized access to user accounts.\n\n Solution:\n\nImplement a method that limits the amount of tries with automated tools.\nSome examples are using a CAPTCHA or a TARPIT(ratelimiting) method.\n\nBe aware that a simple limitation on number of tries may be used as a method to perform denialofservice attack and hence to block certain users like system administrator from logging in. A mechanism combines tries limit with challengeresponse test can be used to prevent this risk while providing convenience for actual user login. For example, start to ask user to complete a CAPTCHA or a TARPIT question during login after a certain number of tries is reached.\n", "checklist_items_id": 14, "checklist_items_checklistID": "2.2.1", "checklist_items_content": "Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks. Such controls include blocking the most common breached passwords, soft lockouts, rate limiting, CAPTCHA, ever increasing delays between attempts, IP address restrictions, or risk-based restrictions such as location, first login on a device, recent attempts to unlock the account, or similar. Verify that no more than 100 failed attempts per hour is possible on a single account.", "checklist_items_type": 1, "include_always": "False", "question_ID": 2, "questions": "Does the sprint implement changes that affect authentication/authorization?"}, {"kb_item_id": "115", "kb_item_title": "Forget password functions", "kb_items_content": " Description:\n\nWhenever the application provides a password forget functionality or another \ntype of recovery methods there are several implementations of hardened proven ways to make\nthe user recover his password.\n\n Solution:\n\nThe recommended solutions are to use TOTP (Timebased OneTime Password algorithm). This \nmethod is an example of a hashbased message authentication code (HMAC). It combines a \nsecret key with the current timestamp using a cryptographic hash function to generate \na onetime password. Because network latency and outofsync clocks can result in the password \nrecipient having to try a range of possible times to authenticate against, the timestamp typically \nincreases in 30second intervals, which thus cuts the potential search space.\n\nOr the other option is to use a Mathematicalalgorithmbased onetime password method. This other \ntype of onetime password uses a complex mathematical algorithm, such as a hash chain, to generate \na series of onetime passwords from a secret shared key. Each password cannot be guessed even when \nprevious passwords are known. The open source OAuth algorithm is standardized; other algorithms are \ncovered by U.S. patents. Each password is observably unpredictable and independent on previous ones. \nTherefore, an adversary would be unable to guess what the next password may be, even with the \nknowledge of all previous passwords.\n\nExample of a hard token mathimatical algorithm would be a yubikey\nExample of a soft token TOTP would be google authenticator\n\nThe last resort would be to send a new password by email. This mail should contain a reset link with \na token which is valid for a limited amount of time. Additional authentication based on softtokens \n(e.g. SMS token, native mobile applications, etc.) can be required as well before the link is \nsent over. Also, make sure whenever such a recovery cycle is started, the application does not \nreveal the user\u2019s current password in any way.\n", "checklist_items_id": 15, "checklist_items_checklistID": "2.2.2", "checklist_items_content": "Verify that the use of weak authenticators (such as SMS and email) is limited to secondary verification and transaction approval and not as a replacement for more secure authentication methods. Verify that stronger methods are offered before weak methods, users are aware of the risks, or that proper measures are in place to limit the risks of account compromise.", "checklist_items_type": 1, "include_always": "False", "question_ID": 2, "questions": "Does the sprint implement changes that affect authentication/authorization?"}, {"kb_item_id": "296", "kb_item_title": "user notification on critical state changing operations", "kb_items_content": "Description:\nWhen a user is informed of critical operations than the user can determine\nif the notification is send by his own actions, or that the notifucation indicates \npotential compromitation of his user account.\n\nSolution:\n\nVerify that secure notifications are sent to users after updates\nto authentication details, such as credential resets, email or address changes,\nlogging in from unknown or risky locations. Users must also be notified when\npassword policies change or any other important updates that require action from the\nuser to increase the security of his account.\n\nThe use of push notifications rather than SMS or email is preferred, but in the \nabsence of push notifications, SMS or email is acceptable as long as no sensitive information is disclosed \nin the notification.\n", "checklist_items_id": 16, "checklist_items_checklistID": "2.2.3", "checklist_items_content": "Verify that secure notifications are sent to users after updates to authentication details, such as credential resets, email or address changes, logging in from unknown or risky locations. The use of push notifications - rather than SMS or email - is preferred, but in the absence of push notifications, SMS or email is acceptable as long as no sensitive information is disclosed in the notification.", "checklist_items_type": 1, "include_always": "False", "question_ID": 2, "questions": "Does the sprint implement changes that affect authentication/authorization?"}, {"kb_item_id": "214", "kb_item_title": "Secrets should be secure random generated", "kb_items_content": " Description:\n\nSecret keys, API tokens, or passwords must be dynamically generated. Whenever these tokens\nare not dynamically generated they can become predicable and used by attackers to compromise\nuser accounts. \n\n Solution:\n\nWhen it comes to API tokens and secret keys these values have to be dynamically generated and valid only once.\nThe secret token should be cryptographically 'random secure', with at least 120 bit of effective entropy, salted with a unique and random 32bit value and hashed with an approved hashing (oneway) function.\n\nPasswords on the other hand should be created by the user himself, rather than assigning\na user a dynamically generated password. The user should be presented a onetime link with a \ncryptographically random token by means of an email or SMS which is used to activate his \naccount and provide a password of his own.\n \n", "checklist_items_id": 17, "checklist_items_checklistID": "2.3.1", "checklist_items_content": "Verify system generated initial passwords or activation codes SHOULD be securely randomly generated, SHOULD be at least 6 characters long, and MAY contain letters and numbers, and expire after a short period of time. These initial secrets must not be permitted to become the long term password.", "checklist_items_type": 1, "include_always": "False", "question_ID": 2, "questions": "Does the sprint implement changes that affect authentication/authorization?"}, {"kb_item_id": "243", "kb_item_title": "Password leakage", "kb_items_content": " Description:\n\nAfter completing a password recovery functionality, the user should not be sent a plaintext\npassword to his email adress. The application should also under no circumstances disclose the old or current password\nto the users.\n\n Solution:\n\nThe application should under no circumstances disclose the users current, old and new password plain text.\nThis behavior makes the application susceptible to side channel attacks and make the passwords\nlose their integrity since they could be compromised by someone looking over another users shoulder to\nsee the password. \n", "checklist_items_id": 18, "checklist_items_checklistID": "2.5.1", "checklist_items_content": "Verify that a system generated initial activation or recovery secret is not sent in clear text to the user. (C6)", "checklist_items_type": 1, "include_always": "False", "question_ID": 2, "questions": "Does the sprint implement changes that affect authentication/authorization?"}, {"kb_item_id": "87", "kb_item_title": "No shared knowledge for secret questions", "kb_items_content": " Description:\n\nWhenever an application ask an user a secret question i.e a password forgot\nfunctionality, these questions should not be shared knowledge an attacker could get from\nthe web to prevent him compromising the account by this function.\n\n Solution:\n\nSecret questions should never include shared knowledge, predictable or easy\nguessable values.\n\nOtherwise the answers for these secret questions can be easilly looked up on the internet by means \nof social media accounts and the like.\n", "checklist_items_id": 19, "checklist_items_checklistID": "2.5.2", "checklist_items_content": "Verify password hints or knowledge-based authentication (so-called \"secret questions\") are not present.", "checklist_items_type": 1, "include_always": "False", "question_ID": 2, "questions": "Does the sprint implement changes that affect authentication/authorization?"}, {"kb_item_id": "243", "kb_item_title": "Password leakage", "kb_items_content": " Description:\n\nAfter completing a password recovery functionality, the user should not be sent a plaintext\npassword to his email adress. The application should also under no circumstances disclose the old or current password\nto the users.\n\n Solution:\n\nThe application should under no circumstances disclose the users current, old and new password plain text.\nThis behavior makes the application susceptible to side channel attacks and make the passwords\nlose their integrity since they could be compromised by someone looking over another users shoulder to\nsee the password. \n", "checklist_items_id": 20, "checklist_items_checklistID": "2.5.3", "checklist_items_content": "Verify password credential recovery does not reveal the current password in any way. (C6)", "checklist_items_type": 1, "include_always": "False", "question_ID": 2, "questions": "Does the sprint implement changes that affect authentication/authorization?"}, {"kb_item_id": "63", "kb_item_title": "Avoid the use of default and predictable acounts.", "kb_items_content": " Description:\n\nWhenever default or predictable accounts are available on an application/server this could\nlead to an attacker compromising these services. Make sure all default and predictable\naccounts are disabled or deleted from the services.\n\n Solution:\n\nVerify that all keys and passwords are replaceable, and are generated or\nreplaced after installation time.\n", "checklist_items_id": 21, "checklist_items_checklistID": "2.5.4", "checklist_items_content": "Verify shared or default accounts are not present (e.g. \"root\", \"admin\", or \"sa\").", "checklist_items_type": 1, "include_always": "True", "question_ID": 0, "questions": null}, {"kb_item_id": "296", "kb_item_title": "user notification on critical state changing operations", "kb_items_content": "Description:\nWhen a user is informed of critical operations than the user can determine\nif the notification is send by his own actions, or that the notifucation indicates \npotential compromitation of his user account.\n\nSolution:\n\nVerify that secure notifications are sent to users after updates\nto authentication details, such as credential resets, email or address changes,\nlogging in from unknown or risky locations. Users must also be notified when\npassword policies change or any other important updates that require action from the\nuser to increase the security of his account.\n\nThe use of push notifications rather than SMS or email is preferred, but in the \nabsence of push notifications, SMS or email is acceptable as long as no sensitive information is disclosed \nin the notification.\n", "checklist_items_id": 22, "checklist_items_checklistID": "2.5.5", "checklist_items_content": "Verify that if an authentication factor is changed or replaced, that the user is notified of this event.", "checklist_items_type": 1, "include_always": "False", "question_ID": 2, "questions": "Does the sprint implement changes that affect authentication/authorization?"}, {"kb_item_id": "115", "kb_item_title": "Forget password functions", "kb_items_content": " Description:\n\nWhenever the application provides a password forget functionality or another \ntype of recovery methods there are several implementations of hardened proven ways to make\nthe user recover his password.\n\n Solution:\n\nThe recommended solutions are to use TOTP (Timebased OneTime Password algorithm). This \nmethod is an example of a hashbased message authentication code (HMAC). It combines a \nsecret key with the current timestamp using a cryptographic hash function to generate \na onetime password. Because network latency and outofsync clocks can result in the password \nrecipient having to try a range of possible times to authenticate against, the timestamp typically \nincreases in 30second intervals, which thus cuts the potential search space.\n\nOr the other option is to use a Mathematicalalgorithmbased onetime password method. This other \ntype of onetime password uses a complex mathematical algorithm, such as a hash chain, to generate \na series of onetime passwords from a secret shared key. Each password cannot be guessed even when \nprevious passwords are known. The open source OAuth algorithm is standardized; other algorithms are \ncovered by U.S. patents. Each password is observably unpredictable and independent on previous ones. \nTherefore, an adversary would be unable to guess what the next password may be, even with the \nknowledge of all previous passwords.\n\nExample of a hard token mathimatical algorithm would be a yubikey\nExample of a soft token TOTP would be google authenticator\n\nThe last resort would be to send a new password by email. This mail should contain a reset link with \na token which is valid for a limited amount of time. Additional authentication based on softtokens \n(e.g. SMS token, native mobile applications, etc.) can be required as well before the link is \nsent over. Also, make sure whenever such a recovery cycle is started, the application does not \nreveal the user\u2019s current password in any way.\n", "checklist_items_id": 23, "checklist_items_checklistID": "2.5.6", "checklist_items_content": "Verify forgotten password, and other recovery paths use a secure recovery mechanism, such as TOTP or other soft token, mobile push, or another offline recovery mechanism. ", "checklist_items_type": 1, "include_always": "False", "question_ID": 2, "questions": "Does the sprint implement changes that affect authentication/authorization?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 24, "checklist_items_checklistID": "2.7.1", "checklist_items_content": "Verify that clear text out of band (NIST \"restricted\") authenticators, such as SMS or PSTN, are not offered by default, and stronger alternatives such as push notifications are offered first.", "checklist_items_type": 1, "include_always": "False", "question_ID": 2, "questions": "Does the sprint implement changes that affect authentication/authorization?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 25, "checklist_items_checklistID": "2.7.2", "checklist_items_content": "Verify that the out of band verifier expires out of band authentication requests, codes, or tokens after 10 minutes.", "checklist_items_type": 1, "include_always": "False", "question_ID": 2, "questions": "Does the sprint implement changes that affect authentication/authorization?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 26, "checklist_items_checklistID": "2.7.3", "checklist_items_content": "Verify that the out of band verifier authentication requests, codes, or tokens are only usable once, and only for the original authentication request.", "checklist_items_type": 1, "include_always": "False", "question_ID": 2, "questions": "Does the sprint implement changes that affect authentication/authorization?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 27, "checklist_items_checklistID": "2.7.4", "checklist_items_content": "Verify that the out of band authenticator and verifier communicates over a secure independent channel.", "checklist_items_type": 1, "include_always": "False", "question_ID": 2, "questions": "Does the sprint implement changes that affect authentication/authorization?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 28, "checklist_items_checklistID": "2.8.1", "checklist_items_content": "Verify that time-based OTPs have a defined lifetime before expiring.", "checklist_items_type": 1, "include_always": "False", "question_ID": 32, "questions": "Does the sprint introduce changes that affect OTP?"}, {"kb_item_id": null, "kb_item_title": null, "kb_items_content": null, "checklist_items_id": 29, "checklist_items_checklistID": "3.0", "checklist_items_content": "Session Management Verification Requirements", "checklist_items_type": 1, "include_always": "False", "question_ID": 0, "questions": null}, {"kb_item_id": "91", "kb_item_title": "Verify that the sensitive information is never disclosed", "kb_items_content": " Description:\n\nInformation exposure through query strings in URL is when sensitive data is passed to parameters in the URL. This allows attackers to obtain sensitive data such as usernames, passwords, tokens (authX), database details, and any other potentially sensitive data. Simply using HTTPS does not resolve this vulnerability.\n\nRegardless of using encryption, the following URL will expose information in the locations detailed below: https://vulnerablehost.com/authuser?user=bob&authz_token=1234&expire=1500000000\n\nThe parameter values for 'user', 'authz_token', and 'expire' will be exposed in the following locations \nwhen using HTTP or HTTPS:\n\n Referer Header\n Web Logs\n Shared Systems\n Browser History\n Browser Cache\n Shoulder Surfing\n\nWhen not using an encrypted channel, all of the above and the following:\n ManintheMiddle\n\n\n Solution:\n\nSensitive informtion should never be included in the URL.\n", "checklist_items_id": 30, "checklist_items_checklistID": "3.1.1", "checklist_items_content": "Verify the application never reveals session tokens in URL parameters or error messages.", "checklist_items_type": 1, "include_always": "False", "question_ID": 3, "questions": "Does the sprint implement changes that affect session management?"}, {"kb_item_id": "58", "kb_item_title": "The login functionality should always generate a new session id", "kb_items_content": " Description:\n\nWhenever an user is successfully authenticated the application should generate a\nnew session cookie.\n\n Solution:\n\nThe login functionality should always generate (and use) a new session ID after a\nsuccessful login. This is done to prevent an attacker doing a session fixation attack\non your users.\n\nSome frameworks do not provide the possibility to change the session ID on login such as\n.net applications. Whenever this problem occurs you could set an extra random cookie on\nlogin with a strong token and store this value in a session variable.\n\nNow you can compare the cookie value with the session variable in order to prevent\nsession fixation since the authentication does not solely rely on the session ID since\nthe random cookie can not be predicted or fixated by the attacker.\n", "checklist_items_id": 31, "checklist_items_checklistID": "3.2.1", "checklist_items_content": "Verify the application generates a new session token on user authentication. (C6)", "checklist_items_type": 1, "include_always": "False", "question_ID": 3, "questions": "Does the sprint implement changes that affect session management?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 32, "checklist_items_checklistID": "3.2.2", "checklist_items_content": "Verify that session tokens possess at least 64 bits of entropy. (C6)", "checklist_items_type": 1, "include_always": "False", "question_ID": 3, "questions": "Does the sprint implement changes that affect session management?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 33, "checklist_items_checklistID": "3.2.3", "checklist_items_content": "Verify the application only stores session tokens in the browser using secure methods such as appropriately secured cookies (see section 3.4) or HTML 5 session storage.", "checklist_items_type": 1, "include_always": "False", "question_ID": 3, "questions": "Does the sprint implement changes that affect session management?"}, {"kb_item_id": "57", "kb_item_title": "The logout functionality should revoke the complete session", "kb_items_content": " Description:\n\nWhen the logout functionality does not revoke the complete session, an attacker could still\nimpersonate a user when he has access to the session cookie even after the user is logged off the application.\n\n Solution:\n\nThe logout functionality should revoke the complete session whenever a user\nwants to terminate his session.\n\nEach different framework has its own guide to achieve this revocation.\nIt is also recommended for you to make test cases which you follow to ensure\nsession revocation in your application.\n", "checklist_items_id": 34, "checklist_items_checklistID": "3.3.1", "checklist_items_content": "Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties. (C6)", "checklist_items_type": 1, "include_always": "False", "question_ID": 3, "questions": "Does the sprint implement changes that affect session management?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 35, "checklist_items_checklistID": "3.3.2", "checklist_items_content": "If authenticators permit users to remain logged in, verify that re-authentication occurs periodically both when actively used or after an idle period. (C6)", "checklist_items_type": 1, "include_always": "False", "question_ID": 3, "questions": "Does the sprint implement changes that affect session management?"}, {"kb_item_id": "254", "kb_item_title": "Password change leads to destroying concurrent sessions", "kb_items_content": " Description:\n\nWhenever a user changes his password, the user should be granted the option\nto kill all other concurrent sessions. This countermessure helps to exclude\npotential attackers living on a hijacked session.\n\nNote: Whenever users are granted the possibility to change their passwords,\n do not forget to make them reauthenticate or to use a form of step up\n or adaptive authentication mechanism.\n\n Solution:\n\nVerify the user is prompted with the option to terminate all other active sessions \nafter a successful change password process.\n", "checklist_items_id": 36, "checklist_items_checklistID": "3.3.3", "checklist_items_content": "Verify that the application terminates all other active sessions after a successful password change, and that this is effective across the application, federated login (if present); and any relying parties.", "checklist_items_type": 1, "include_always": "False", "question_ID": 3, "questions": "Does the sprint implement changes that affect session management?"}, {"kb_item_id": "188", "kb_item_title": "concurrent session handling", "kb_items_content": " Description:\n\nYou should limit and keep track of all the different active concurrent sessions.\nWhenever the application discovers concurrent sessions it should always notify the user\nabout this and should give him the opportunity to end the other sessions.\n\nWith this defense in place it becomes harder for attackers to hijack a users session since\nthey will be notified about concurrent sessions.\n\n Solution:\n\nThe application should keep track and limit all the granted sessions.\nIt should store your users IP address, session id and user id. After storing these credentials\nit should do regular checks to see if there are:\n\n1. Multiple active sessions linked to same user id\n2. Multiple active sessions from different locations\n3. Multiple active sessions from different devices\n4. Limit and destroy sessions when they exceed an accepted threshold.\n\nThe more critical the application becomes the lower the accepted threshold for\nconcurrent sessions should be.\n\n\n", "checklist_items_id": 37, "checklist_items_checklistID": "3.3.4", "checklist_items_content": "Verify that users are able to view and log out of any or all currently active sessions and devices.", "checklist_items_type": 1, "include_always": "False", "question_ID": 3, "questions": "Does the sprint implement changes that affect session management?"}, {"kb_item_id": "38", "kb_item_title": "Session cookies without the Secure attribute", "kb_items_content": " Description:\n\nThe secure flag is an option that can be set when creating a cookie.\nThis flag ensures that the cookie will not be sent over an unencrypted\nconnection by the browser,which ensures that the session cookie can not be sent over a nonencrypted link.\n\n Solution:\n\nWhen creating a session cookie which is sent over an encrypted connection\nyou should set the secure flag. The Secure flag should be set during every setcookie.\nThis will instruct the browser to never send the cookie over HTTP.\nThe purpose of this flag is to prevent the accidental exposure of a cookie value if a user\nfollows an HTTP link.\n\n\n", "checklist_items_id": 38, "checklist_items_checklistID": "3.4.1", "checklist_items_content": "Verify that cookie-based session tokens have the 'Secure' attribute set. (C6)", "checklist_items_type": 1, "include_always": "False", "question_ID": 3, "questions": "Does the sprint implement changes that affect session management?"}, {"kb_item_id": "39", "kb_item_title": "Session cookies without the HttpOnly attribute", "kb_items_content": " Description:\n\nAn HttpOnly flag is an option that can be set when creating a cookie. This v ensures that the cookie cannot be read or edited by JavaScript. This ensures an attacker cannot steal this cookie as a crosssite scripting vulnerability is present in the application.\n\n Solution:\n\nThe HttpOnly flag should be set to disable malicious script access to the cookie values such as the session ID value. Also, disable unnecessary HTTP request methods such as the TRACE option. Misconfiguration of the HTTP request headers can lead to stealing the session cookie even though HttpOnly protection is in place.\n", "checklist_items_id": 39, "checklist_items_checklistID": "3.4.2", "checklist_items_content": "Verify that cookie-based session tokens have the 'HttpOnly' attribute set. (C6)", "checklist_items_type": 1, "include_always": "False", "question_ID": 3, "questions": "Does the sprint implement changes that affect session management?"}, {"kb_item_id": "291", "kb_item_title": "same site attribute", "kb_items_content": "Description:\nSameSite prevents the browser from sending this cookie along with crosssite requests. \nThe main goal is mitigate the risk of crossorigin information leakage. It also provides some \nprotection against crosssite request forgery attacks.\n\n\nSolution:\nThe strict value will prevent the cookie from being sent by the browser to the target site in all \ncrosssite browsing context, even when following a regular link. For example, for a GitHublike website this \nwould mean that if a loggedin user follows a link to a private GitHub project posted on a corporate discussion \nforum or email, GitHub will not receive the session cookie and the user will not be able to access the project.\n\nA bank website however most likely doesn't want to allow any transactional pages to be linked from external \nsites so the strict flag would be most appropriate here.\n\nThe default lax value provides a reasonable balance between security and usability for websites that want\nto maintain user's loggedin session after the user arrives from an external link. In the above GitHub scenario, \nthe session cookie would be allowed when following a regular link from an external website while blocking it in \nCSRFprone request methods (e.g. POST).\n\nAs of November 2017 the SameSite attribute is implemented in Chrome, Firefox, and Opera. \nSince version 12.1 Safari also supports this. Windows 7 with IE 11 lacks support as of December 2018, \nsee caniuse.com below.\n", "checklist_items_id": 40, "checklist_items_checklistID": "3.4.3", "checklist_items_content": "Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks. (C6)", "checklist_items_type": 1, "include_always": "False", "question_ID": 3, "questions": "Does the sprint implement changes that affect session management?"}, {"kb_item_id": "292", "kb_item_title": "host prefix", "kb_items_content": "Description:\n\nthe 'Host\" prefix signals to the browser that both the Path=/ and Secure attributes are required, \nand at the same time, that the Domain attribute may not be present.\n\n", "checklist_items_id": 41, "checklist_items_checklistID": "3.4.4", "checklist_items_content": "Verify that cookie-based session tokens use \"Host-\" prefix (see references) to provide session cookie confidentiality.", "checklist_items_type": 1, "include_always": "False", "question_ID": 3, "questions": "Does the sprint implement changes that affect session management?"}, {"kb_item_id": "158", "kb_item_title": "Cross subdomain cookie attack", "kb_items_content": " Description:\n\nA quick overview of how it works:\n\n1. A website www.example.com hands out subdomains to untrusted third parties\n2. One such party, Mallory, who now controls evil.example.com, lures Alice to her site\n3. A visit to evil.example.com sets a session cookie with the domain .example.com on Alice's browser\n4. When Alice visits www.example.com, this cookie will be sent with the request, as the specs for cookies states, and Alice will have the session specified by Mallory's cookie.\n5. Mallory can now use Alice her account.\n\n Solution:\n\nIn this scenario changing the sessionID on login does not make any difference since\nAlice is already logged in when she visits Mallory's evil web page.\n\nIt is good practice to use a completely different domain for all trusted activity.\n\nFor example Google uses google.com for trusted activities and *.googleusercontent.com\nfor untrusted sites.\n\nAlso when setting your cookies to specify which domains they are allowed to\nbe send to. Especially on your trusted domain you do not want to leak cookies to unintended\nsubdomains. highly recommended is to not use wildcards when setting this option.\n", "checklist_items_id": 42, "checklist_items_checklistID": "3.4.5", "checklist_items_content": "Verify that if the application is published under a domain name with other applications that set or use session cookies that might override or disclose the session cookies, set the path attribute in cookie-based session tokens using the most precise path possible. (C6)", "checklist_items_type": 1, "include_always": "False", "question_ID": 3, "questions": "Does the sprint implement changes that affect session management?"}, {"kb_item_id": "233", "kb_item_title": "High value transactions", "kb_items_content": " Description:\n\nWhenever there are high value transactions a normal username/password static authentication method does\nnot suffice to ensure a high level of security. Whenever the application digests high level of transactions ensure that\nrisk based reauthentication, two factor or transaction signing is in place.\n\n Solution:\n\n1 risk based authentication:\nIn Authentication, riskbased authentication is a nonstatic authentication \nsystem which takes into account the profile of the agent requesting access to \nthe system to determine the risk profile associated with that transaction. \n\nThe risk profile is then used to determine the complexity of the challenge.\nHigher risk profiles leads to stronger challenges, whereas a static username/password may suffice for \nlowerrisk profiles. Riskbased implementation allows the application to challenge the user for additional \ncredentials only when the risk level is appropriate.\n\n2 two factor authentication:\nMultifactor authentication (MFA) is a method of computer access control in which a user is \ngranted access only after successfully presenting several separate pieces of evidence to an \nauthentication mechanism \u2013 typically at least two of the following categories: knowledge (something they know), \npossession (something they have), and inherence (something they are)\n\n3 Transaction signing:\nTransaction signing (or digital transaction signing) is the process of calculating a keyed hash function \nto generate a unique string which can be used to verify both the authenticity and integrity of an online transaction.\n\nA keyed hash is a function of the user's private or secret key and the transaction details, \nsuch as the transfer to the account number and the transfer amount.\n\nTo provide a high level of assurance of the authenticity and integrity of \nthe hash it is essential to calculate the hash on a trusted device, such as a separate smart card reader.\nCalculating a hash on an Internetconnected PC or mobile device such as a mobile telephone/PDA would be\ncounterproductive as malware and attackers can attack these platforms and potentially subvert the signing process itself.\n", "checklist_items_id": 43, "checklist_items_checklistID": "3.7.1", "checklist_items_content": "Verify the application ensures a valid login session or requires re-authentication or secondary verification before allowing any sensitive transactions or account modifications.", "checklist_items_type": 1, "include_always": "False", "question_ID": 3, "questions": "Does the sprint implement changes that affect session management?"}, {"kb_item_id": null, "kb_item_title": null, "kb_items_content": null, "checklist_items_id": 44, "checklist_items_checklistID": "4.0", "checklist_items_content": "Access Control Verification Requirements", "checklist_items_type": 1, "include_always": "False", "question_ID": 0, "questions": null}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 45, "checklist_items_checklistID": "4.1.1", "checklist_items_content": "Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed.", "checklist_items_type": 1, "include_always": "False", "question_ID": 4, "questions": "Does the sprint implement changes that affect access control systems?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 46, "checklist_items_checklistID": "4.1.2", "checklist_items_content": "Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized.", "checklist_items_type": 1, "include_always": "False", "question_ID": 4, "questions": "Does the sprint implement changes that affect access control systems?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 47, "checklist_items_checklistID": "4.1.3", "checklist_items_content": "Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege. (C7)", "checklist_items_type": 1, "include_always": "False", "question_ID": 4, "questions": "Does the sprint implement changes that affect access control systems?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 48, "checklist_items_checklistID": "4.1.4", "checklist_items_content": "Verify that the principle of deny by default exists whereby new users/roles start with minimal or no permissions and users/roles do not receive access to new features until access is explicitly assigned. ", "checklist_items_type": 1, "include_always": "False", "question_ID": 4, "questions": "Does the sprint implement changes that affect access control systems?"}, {"kb_item_id": "114", "kb_item_title": "All authentication controls must fail securely", "kb_items_content": " Description:\n\nHandling errors securely is a key aspect of secure coding.\nThere are two types of errors that deserve special attention. The first is exceptions\nthat occur in the processing of a security control itself. It's important that these\nexceptions do not enable behavior that the countermeasure would normally not allow.\nAs a developer, you should consider that there are generally three possible outcomes\nfrom a security mechanism:\n\n1. Allow the operation\n2. Disallow the operation\n3. Exception\n\nIn general, you should design your security mechanism so that a failure will follow the same execution path\nas disabling the operation\n\n Solution:\n\nMake sure all the access control systems are thoroughly tested for failing securely before\nusing it in your application. It is common that complete unittest are created especially\nfor this purpose.\n", "checklist_items_id": 49, "checklist_items_checklistID": "4.1.5", "checklist_items_content": "Verify that access controls fail securely including when an exception occurs. (C10)", "checklist_items_type": 1, "include_always": "False", "question_ID": 4, "questions": "Does the sprint implement changes that affect access control systems?"}, {"kb_item_id": "268", "kb_item_title": "Insecure direct object references", "kb_items_content": " Description:\n\nApplications frequently use the actual name or key of an object when generating web pages. \nApplications don\u2019t always verify the user is authorized for the target object. \nThis results in an insecure direct object reference flaw. Testers can easily manipulate parameter \nvalues to detect such flaws and code analysis quickly shows whether authorization is properly verified.\n\nThe most classic example:\nThe application uses unverified data in a SQL call that is accessing account information:\n\nString query = \"SELECT * FROM accts WHERE account = ?\";\nPreparedStatement pstmt = connection.prepareStatement(query , ... );\npstmt.setString( 1, request.getParameter(\"acct\"));\nResultSet results = pstmt.executeQuery();\n\nThe attacker simply modifies the \u2018acct\u2019 parameter in their browser to send whatever \naccount number they want. If not verified, the attacker can access any user\u2019s account, instead of \nonly the intended customer\u2019s account.\n\nhttp://example.com/app/accountInfo?acct=notmyacct\n\n Solution:\n\nPreventing insecure direct object references requires selecting an approach \nfor protecting each user accessible object (e.g., object number, filename):\n\nUse per user or session indirect object references. This prevents attackers from directly \ntargeting unauthorized resources. For example, instead of using the resource\u2019s database key, \na drop down list of six resources authorized for the current user could use the numbers 1 to 6 to \nindicate which value the user selected. The application has to map the peruser indirect reference \nback to the actual database key on the server.\n\nCheck access. Each use of a direct object reference from an untrusted source must include an access control \ncheck to ensure the user is authorized for the requested object.\n", "checklist_items_id": 50, "checklist_items_checklistID": "4.2.1", "checklist_items_content": "Verify that sensitive data and APIs are protected against direct object attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records.", "checklist_items_type": 1, "include_always": "False", "question_ID": 4, "questions": "Does the sprint implement changes that affect access control systems?"}, {"kb_item_id": "5", "kb_item_title": "Cross site request forgery", "kb_items_content": " Description:\n\nCrossSite Request Forgery (CSRF) is a type of attack that occurs when a malicious Web site,\nemail, blog, instant message, or program causes a users Web browser to perform an unwanted\naction on a trusted site for which the user is currently authenticated.\n\nThe impact of a successful crosssite request forgery attack is limited to the\ncapabilities exposed by the vulnerable application. For example, this attack could result\nin a transfer of funds, changing a password, or purchasing an item in the users context.\nIn effect, CSRF attacks are used by an attacker to make a target system perform a\nfunction (funds Transfer, form submission etc.) via the targets browser without\nknowledge of the target user at least until the unauthorised function has been committed.\n\n Solution:\n\nTo arm an application against automated attacks and tooling you need to use unique tokens\nwhich are included into the forms of an application, API calls or AJAX requests. \nAny state changing operation requires a secure random token (e.g CSRF token) to prevent\nagainst CSRF attacks. Characteristics of a CSRF Token are a unique, large random\nvalue generated by a cryptographically secure random number generator.\n\nThe CSRF token is then added as a hidden field for forms and validated on the sever side whenever\na user is sending a request to the server.\n\nNote :\nWhenever the application is an REST service and is using tokens such as JWT tokens, whenever these tokens are being sent\nin the application headers rather than stored in cookies the application should not be suspectible to CSRF attacks for a succesfull CSRF attacke depends on the browsers cookie jar.\n", "checklist_items_id": 51, "checklist_items_checklistID": "4.2.2", "checklist_items_content": "Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality, and effective anti-automation or anti-CSRF protects unauthenticated functionality.", "checklist_items_type": 1, "include_always": "False", "question_ID": 4, "questions": "Does the sprint implement changes that affect access control systems?"}, {"kb_item_id": "231", "kb_item_title": "Two factor authentication", "kb_items_content": " Description:\n\nTwo factor authenitcation must be implemented to protect your applications users against unauthorized use of the application.\n\nWhenever the users username and password are leaked or disclosed by an application on what ever fashion possible, the \nusers account should still be proteced by two factor authentication mechanisms to prevent attackers\nfrom logging in with the credentials.\n\n\n Solution:\n\nMultifactor authentication (MFA) is a method of computer access control in which a user is granted access only after successfully presenting several separate pieces of evidence to an authentication mechanism \u2013 typically at least two of the following categories: knowledge (something they know), possession (something they have), and inherence (something they are)\n\nExamples of two/multi factor authentication can be \n\n1. Google authenticator\n Google Authenticator is an application that implements twostep verification services using the Timebased \n Onetime Password Algorithm (TOTP) and HMACbased Onetime Password Algorithm \n\n2. Yubikey\n\n The YubiKey is a hardware authentication device manufactured by Yubico that supports onetime passwords, public key \n encryption and authentication, and the Universal 2nd Factor (U2F) protocol[1] developed by the FIDO Alliance (FIDO U2F).\n It allows users to securely log into their accounts by emitting onetime passwords or using a FIDObased public/private\n key pair generated by the device\n", "checklist_items_id": 52, "checklist_items_checklistID": "4.3.1", "checklist_items_content": "Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use.", "checklist_items_type": 1, "include_always": "False", "question_ID": 4, "questions": "Does the sprint implement changes that affect access control systems?"}, {"kb_item_id": "61", "kb_item_title": "Directory listing", "kb_items_content": " Description:\n\nWhenever directory listing is enabled, an attacker could gain sensitive information about\nthe systems hierarchical structure and gain knowledge about directories or files which should\npossibly not be publicly accessible. An attacker could use this information to\nincrease his attack vector. In some cases this could even lead to an attacker gaining knowledge about\ncredentials or old vulnerable system demo functions which might lead to remote code execution.\n\n Solution:\n\nDifferent types of servers require a different type of approach in order to disable\ndirectory listing. For instance: Apache uses a .htacces in order to disable directory listing.\nAs for iis7, directory listing is disabled by default.\n", "checklist_items_id": 53, "checklist_items_checklistID": "4.3.2", "checklist_items_content": "Verify that directory browsing is disabled unless deliberately desired. Additionally, applications should not allow discovery or disclosure of file or directory metadata, such as Thumbs.db, .DS_Store, .git or .svn folders.", "checklist_items_type": 1, "include_always": "False", "question_ID": 4, "questions": "Does the sprint implement changes that affect access control systems?"}, {"kb_item_id": "111", "kb_item_title": "Step up or adaptive authentication", "kb_items_content": " Description:\n\nWhenever a user browses a section of a webbased application that contains sensitive information the user should be challenged authenticate again using a higher assurance credential to be granted access to this information.\nThis is to prevent attackers from reading sensitive information after they successfully hijacked a user account.\n\n\n Solution:\n\nVerify the application has additional authorization (such as step up or adaptive authentication) so the user is challenged before being granted access to sensitive information. This rule also applies for making critical changes to an account or action.\nSegregation of duties should be applied for highvalue applications to enforce antifraud controls as per the risk of application and past fraud.\n\n", "checklist_items_id": 54, "checklist_items_checklistID": "4.3.3", "checklist_items_content": "Verify the application has additional authorization (such as step up or adaptive authentication) for lower value systems, and / or segregation of duties for high value applications to enforce anti-fraud controls as per the risk of application and past fraud.", "checklist_items_type": 1, "include_always": "False", "question_ID": 4, "questions": "Does the sprint implement changes that affect access control systems?"}, {"kb_item_id": null, "kb_item_title": null, "kb_items_content": null, "checklist_items_id": 55, "checklist_items_checklistID": "5.0", "checklist_items_content": "Validation, Sanitization and Encoding Verification Requirements", "checklist_items_type": 1, "include_always": "False", "question_ID": 0, "questions": null}, {"kb_item_id": "71", "kb_item_title": "HTTP header injection", "kb_items_content": " Description:\n\nHTTP header injection is a general class of web application security vulnerability which\noccurs when Hypertext Transfer Protocol (HTTP) headers are\ndynamically generated based on user input. Header injection in HTTP responses can allow\nfor HTTP response splitting (also known as CRLF, Carriage Return Line Feed),\nSession fixation via the SetCookie header, crosssite scripting (XSS),\nand malicious redirect attacks via the location header. HTTP header injection is a\nrelatively new area for webbased attacks, and has primarily been pioneered\nby Amit Klein in his work on request/response smuggling/splitting.\nVulnerabilities due to HTTP header injections such as CRLF are no longer\nfeasible due to the fact that multiple header requests are not possible.\n\n Solution:\n\nWhen userinput will be used in HTTP headers then the newlines should be escaped in a\ncorrect manner. Recommended would be a whitelist of expected input or use a validation method\nwhich for example only accepts alphanumeric values. Every detection of input which is out of\nthe intended operation should be rejected.\n", "checklist_items_id": 56, "checklist_items_checklistID": "5.1.1", "checklist_items_content": "Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (GET, POST, cookies, headers, or environment variables).", "checklist_items_type": 1, "include_always": "False", "question_ID": 0, "questions": null}, {"kb_item_id": "147", "kb_item_title": "Automatic parameter binding", "kb_items_content": " Description:\n\nIf the application framework allows automatic mass parameter assignment\n(also called automatic variable binding) from the inbound request to a model,\nverify that security sensitive fields such as 'accountBalance', 'role' or 'password'\nare protected from malicious automatic binding. Whenever your application takes parameters\nin HTTPs GET statement and passes them as variables to code within the application this\ncould become a safety hazard since the application processes these variables\nin his operations.\n\n Solution:\n\nWhen working with automatic variable binding you should create whitelists of what\nparameters are expected and allow only these parameters to be passed into your\napplication operation.\n", "checklist_items_id": 57, "checklist_items_checklistID": "5.1.2", "checklist_items_content": "Verify that frameworks protect against mass parameter assignment attacks, or that the application has countermeasures to protect against unsafe parameter assignment, such as marking fields private or similar. (C5)", "checklist_items_type": 1, "include_always": "False", "question_ID": 5, "questions": "Does the sprint make use/implement an ORM framework? (object relational model)"}, {"kb_item_id": "167", "kb_item_title": "Positive validation model", "kb_items_content": " Description:\n\nThere are two popular methods for handling input validation. The first is blacklisting and the second one is the whitelisting method, also known as a positive validation model.\nThe big disadvantage of the blacklisting model would be that an attacker has a great diversity into forging his attack strings and payloads which can make it hard for your application to detect all of them. It would be very time consuming importing them all into your system.\nWhenever you are using a positive validation model you are simply checking for the input you were expecting as defined in your application\u2019s operation, for example:\n\nLet's say you have a form and were expecting it to return the value of a checkbox. This would be a fixed value, yes or no? Whenever the value diverges from the expected input in the applications operation you can assume there was an intercepting proxy tampering these values and act accordingly to it. \nSame goes for whenever you were expecting just a string, integer, alphanumeric character or even special strings such as names as O\u2019Reily.\nThis method also makes your code clear, transparent and highly maintainable.\n\n Solution:\n\nFirst there must be a client side input validation method as you would apply to the server\nside. This means you should also apply input rejection as well as typecasting and such.\nThis is to prevent users from being attacked by XSS attacks which are undetectable by\nthe server.\n\n", "checklist_items_id": 58, "checklist_items_checklistID": "5.1.3", "checklist_items_content": "Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (whitelisting)", "checklist_items_type": 1, "include_always": "False", "question_ID": 6, "questions": "Does the sprint implement functions that handle user supplied input? (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc)"}, {"kb_item_id": "234", "kb_item_title": "Verify that structured data is strongly typed and validated", "kb_items_content": " Description:\n\nWhenever structured data is strongly typed and validated against a defined schema the application\ncan be developed as a defensible proactive application. The application can now measure everything\nthat is outside of its intending operation by means of the defined schema's and should be used to\nreject the input if the schema checks return false.\n\n\n Solution:\n\nVerify that structured data is strongly typed and validated against a defined schema\nincluding allowed characters, length and pattern (e.g. credit card numbers or telephone, \nor validating that two related fields are reasonable, such as validating suburbs and zip or \npost codes match\n", "checklist_items_id": 59, "checklist_items_checklistID": "5.1.4", "checklist_items_content": "Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers or telephone, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match). (C5)", "checklist_items_type": 1, "include_always": "False", "question_ID": 6, "questions": "Does the sprint implement functions that handle user supplied input? (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc)"}, {"kb_item_id": "67", "kb_item_title": "Open forward and Open redirects", "kb_items_content": " Description:\n\nUnvalidated redirects and forwards are possible when a web application accepts untrusted\ninput that could cause the web application to redirect the request to a URL contained\nwithin the untrusted input. By modifying untrusted URL input to a malicious site, an attacker\nmay successfully launch a phishing scam and steal user credentials. Because the server\nname in the modified link is identical to the original site, phishing attempts may have\na more trustworthy appearance. Unvalidated redirect and forward attacks can also be used\nto maliciously craft a URL that would pass the application's access control check and\nthen forward the attacker to privileged functions that they would normally not be able\nto access.\n\n Solution:\n\nUse a whitelisting method for determining where the user should be redirected towards.\nYou could also show a warning when redirecting to potentially untrusted content.\n\nIf not deemed necessary user supplied input should not be used in redirects and forwards anyways.\n", "checklist_items_id": 60, "checklist_items_checklistID": "5.1.5", "checklist_items_content": "Verify that URL redirects and forwards only allow whitelisted destinations, or show a warning when redirecting to potentially untrusted content.", "checklist_items_type": 1, "include_always": "False", "question_ID": 7, "questions": "Does the sprint implement functions that forward or redirect your users trough the application?"}, {"kb_item_id": "180", "kb_item_title": "WYSIWYG editors", "kb_items_content": " Description:\n\nWYSIWYG editors can be a great risk to your web application since it allows direct\nHTML as input to make the user perform styling on their submissions. This is why the\neditor should be put under a strict sanitation protocol to prevent injections.\n\nThe first thing to take into consideration whenever you want to use WYSIWYG editors on\nyour web application is to use as limited options as possible. Only the options which\nare necessary for your applications intended operation should be applied. This decreases\nthe attackers attack vector drastically and leaves less room for error in your WYSIWYG\neditor in terms of your HTML sanitation.\n\nWhen providing your web application with an WYSIWYG editor you should also take note that\nmost people just want to use bullets, make text bold or underline some text. They mostly\ndo not understand half the functionalities the editors are providing.\n\n Solution:\n\nDownload a HTML sanitizer and configure it to your specific needs. When configuring the sanitizer make sure\nyou disable all unused components. The less options an attacker has to insert into your application the less\nhis attack surface becomes. Also before implementing this HTML sanitizer on a production environment have\nit first thoroughly examined by security testers since it is a very delicate function.\n", "checklist_items_id": 61, "checklist_items_checklistID": "5.2.1", "checklist_items_content": "Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature. (C5)", "checklist_items_type": 1, "include_always": "False", "question_ID": 8, "questions": "Does the sprint implement functions that utilize wysiwyg editors?"}, {"kb_item_id": "269", "kb_item_title": "type checking and length checking", "kb_items_content": " Description\n\nType checking, length checking and whitelisting is an essential in defense in depth strategie to make\nyour application more resiliant against input injection attacks.\n\nExample:\n \n SELECT * FROM pages WHERE id=mysql_real_escape_string($_GET['id'])\n\n \nThis PHP example did effectively not mitigate the SQL injection. This was due to the fact\nthat it only escaped string based SQL injection. \n\nNow, if this application also had additional checks to validate if the value of \nthe $_GET['id'] parameter was indeed as expected an integer and rejected if this condition was false, \nthe attack would effectively been mitigated.\n\n\n Solution\n\nAll the user supplied input that works outside of the intended opteration of the application\nshould be rejected by the application.\n\nSyntax and Semantic Validity\nAn application should check that data is both syntactically and semantically \nvalid (in that order) before using it in any way (including displaying it back to the user). \n\nSyntax validity, means that the data is in the form that is expected. For example, an application\nmay allow a user to select a fourdigit \u201caccount ID\u201d to perform some kind of operation. \nThe application should assume the user is entering a SQL injection payload, and should \ncheck that the data entered by the user is exactly four digits in length, and consists only of numbers \n(in addition to utilizing proper query parameterization).\n\nSemantic validity, includes only accepting input that is within an acceptable range for the\ngiven application functionality and context. For example, a start date must be before an end\ndate when choosing date ranges.\n\n", "checklist_items_id": 62, "checklist_items_checklistID": "5.2.2", "checklist_items_content": "Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.", "checklist_items_type": 1, "include_always": "False", "question_ID": 6, "questions": "Does the sprint implement functions that handle user supplied input? (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc)"}, {"kb_item_id": "270", "kb_item_title": "SMTP IMAP injection", "kb_items_content": " Description:\n\nThis threat affects all applications that communicate with mail servers (IMAP/SMTP), generally webmail \napplications. The aim of this test is to verify the capacity to inject arbitrary IMAP/SMTP commands into\nthe mail servers, due to input data not being properly sanitized.\n\n\nThe IMAP/SMTP Injection technique is more effective if the mail server is not directly accessible from Internet.\nWhere full communication with the backend mail server is possible, it is recommended to conduct direct testing.\n\n\nAn IMAP/SMTP Injection makes it possible to access a mail server which otherwise would not be directly accessible\nfrom the Internet. In some cases, these internal systems do not have the same level of infrastructure security and\nhardening that is applied to the frontend web servers. Therefore, mail server results may be more vulnerable to\nattacks by end users\n", "checklist_items_id": 63, "checklist_items_checklistID": "5.2.3", "checklist_items_content": "Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.", "checklist_items_type": 1, "include_always": "False", "question_ID": 26, "questions": "Does the sprint implement functions that allow users to send emails?"}, {"kb_item_id": "4", "kb_item_title": "Command injection", "kb_items_content": " Description:\n\nCommand injection is an attack in which the goal is execution of arbitrary commands on\nthe host operating system via a vulnerable application. Command injection attacks are\npossible when an application passes unsafe user supplied data\n(forms, cookies, HTTP headers etc.) to a system shell. In this attack,\nthe attackersupplied operating system commands are usually executed with the privileges\nof the vulnerable application. Command injection attacks are possible largely due to\ninsufficient input validation. This attack differs from Code Injection, in that code\ninjection allows the attacker to adds his own code that is then executed by the application.\nIn Code Injection, the attacker extends the default functionality of the application\nwithout the necessity of executing system commands.\n\n Solution:\n\nUserinput that is used in a shell command should not contain dangerous characters.\nA blacklist of characters is not a good option because it may be difficult to think of\nall of the characters to validate against. A white list containing only allowable\ncharacters should be created to validate the userinput.\n", "checklist_items_id": 64, "checklist_items_checklistID": "5.2.4", "checklist_items_content": "Verify that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed.", "checklist_items_type": 1, "include_always": "False", "question_ID": 6, "questions": "Does the sprint implement functions that handle user supplied input? (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc)"}, {"kb_item_id": "267", "kb_item_title": "server side template injection", "kb_items_content": " Description\n\nWhenever user supplied input is embeded directly into a template when the application\nmakes use of a templeating engine (jinja2, twig, Freemarker), a malicious attacker can inject \nand execute template expressions. More often the injection of template expressions will ultimately \nlead to RCE vulnerabilities.\n\nThis type of vulnerability is also seen a lot through applications that let the user intentionally\nmodify the template to provide users a more flexible way to style the applications pages like\na wiki page or CMS system.\n\n Solution\n\nUser supplied input should never be used directly into a template that uses a templating engine.\nThe following example is a small python flask function that renders user supplied input \nas part of the template. This allows a malicious attacker to even execute arbitrary commands when.\n\n\n @app.errorhandler(404)\n def page_not_found(e):\n template = \"\"\"\n <html>\n <p>{0}</p>\n </html>\n\n \"\"\".format(request.url)\n return render_template_string(template), 404\n\n\nThe prefered way to add the user supplied input to this template would be:\n\n @app.errorhandler(404)\n def page_not_found(e):\n input = request.url\n return render_template(\"errorpage.html\", input = input), 404\n \n\nWheras the content of the errorpage.html would look like\n\n\n <html>\n <p>{{input}}</p>\n </html>\n\n", "checklist_items_id": 65, "checklist_items_checklistID": "5.2.5", "checklist_items_content": "Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed.", "checklist_items_type": 1, "include_always": "False", "question_ID": 9, "questions": "Does the sprint implement functions that utilize templating engines or single page apps such as (Angular, React)"}, {"kb_item_id": "262", "kb_item_title": "Server side request forgery", "kb_items_content": " Description:\n\nServer Side Request Forgery (SSRF) attack, where an attacker abuse the functionality of a\nvulnerable web application to send crafter request which which read or update internal \nresources. Attacker can attack an internal network or application behind the firewall with\nthis attack which is normally not accessible through external network and even attack the\ninternal network web applications.\n\nSSRF attack can be used to make requests to other internal resources for accessing the \nmetadata and to run a port can on the internal network. URL schema such as file:// can\nbe used to read the file from the server. Attackers can use legacy URL schemas such as \ndict, gopher, expect etc which can even cause remote code execution.\n\n Solution:\n\nDisable unused URL schemas which are dangerous like expect://, file:///, ftp://, gopher://.\nProper whitelisting of domain or IP address which you need to access to. Response received from \nthe internal server should not be shown to the attacker. Some services like Memcached, Redis, Elasticsearch and MongoDB do not require authentication by default, so we need to enable \nauthentication for these services.\n", "checklist_items_id": 66, "checklist_items_checklistID": "5.2.6", "checklist_items_content": "Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, use whitelisting of protocols, domains, paths and ports.", "checklist_items_type": 1, "include_always": "False", "question_ID": 6, "questions": "Does the sprint implement functions that handle user supplied input? (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc)"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 67, "checklist_items_checklistID": "5.2.7", "checklist_items_content": "Verify that the application sanitizes, disables, or sandboxes user-supplied SVG scriptable content, especially as they relate to XSS resulting from inline scripts, and foreignObject.", "checklist_items_type": 1, "include_always": "False", "question_ID": 10, "questions": "Does the sprint implement functions that allow for SVG scriptable content to be uploaded/posted?"}, {"kb_item_id": "289", "kb_item_title": "user supplied scriptable or expression template language content", "kb_items_content": "Description:\n\nusersupplied scriptable or expression template language content, such as Markdown, \nCSS or XSL stylesheets, BBCode, or similar are designed to give users the option\nto add a lot of rich styling to the application. However whenever these templates \ndo not filter for harmfull attacks, these templates can be used to leverage\nXSS attacks.\n\n\nSolution:\n\nVerify that the application sanitizes, disables, or sandboxes \nusersupplied scriptable or expression template language content, such as Markdown, \nCSS or XSL stylesheets, BBCode, or similar.\n\nHow this is most effectively done depends on the framework and library you\nare choosing to incorperate. It is advised to investigate how to put up constraints\nfor translating these template syntaxes to HTML tags and what their security\nimplications are. \n", "checklist_items_id": 68, "checklist_items_checklistID": "5.2.8", "checklist_items_content": "Verify that the application sanitizes, disables, or sandboxes user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar.", "checklist_items_type": 1, "include_always": "False", "question_ID": 6, "questions": "Does the sprint implement functions that handle user supplied input? (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc)"}, {"kb_item_id": "269", "kb_item_title": "type checking and length checking", "kb_items_content": " Description\n\nType checking, length checking and whitelisting is an essential in defense in depth strategie to make\nyour application more resiliant against input injection attacks.\n\nExample:\n \n SELECT * FROM pages WHERE id=mysql_real_escape_string($_GET['id'])\n\n \nThis PHP example did effectively not mitigate the SQL injection. This was due to the fact\nthat it only escaped string based SQL injection. \n\nNow, if this application also had additional checks to validate if the value of \nthe $_GET['id'] parameter was indeed as expected an integer and rejected if this condition was false, \nthe attack would effectively been mitigated.\n\n\n Solution\n\nAll the user supplied input that works outside of the intended opteration of the application\nshould be rejected by the application.\n\nSyntax and Semantic Validity\nAn application should check that data is both syntactically and semantically \nvalid (in that order) before using it in any way (including displaying it back to the user). \n\nSyntax validity, means that the data is in the form that is expected. For example, an application\nmay allow a user to select a fourdigit \u201caccount ID\u201d to perform some kind of operation. \nThe application should assume the user is entering a SQL injection payload, and should \ncheck that the data entered by the user is exactly four digits in length, and consists only of numbers \n(in addition to utilizing proper query parameterization).\n\nSemantic validity, includes only accepting input that is within an acceptable range for the\ngiven application functionality and context. For example, a start date must be before an end\ndate when choosing date ranges.\n\n", "checklist_items_id": 69, "checklist_items_checklistID": "5.3.1", "checklist_items_content": "Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, URL Parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as \u306d\u3053 or O'Hara).", "checklist_items_type": 1, "include_always": "False", "question_ID": 11, "questions": "Does the sprint implement functions that reflect user supplied input on the side of the client?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 70, "checklist_items_checklistID": "5.3.2", "checklist_items_content": "Verify that output encoding preserves the user's chosen character set and locale, such that any Unicode character point is valid and safely handled.", "checklist_items_type": 1, "include_always": "False", "question_ID": 11, "questions": "Does the sprint implement functions that reflect user supplied input on the side of the client?"}, {"kb_item_id": "3", "kb_item_title": "XSS injection", "kb_items_content": " Description:\n\nEvery time the application gets userinput, whether this showing it on screen or processing\nthis data in the application background, these parameters should be escaped for malicious\ncode in order to prevent crosssite scripting injections.\nWhen an attacker gains the possibility to perform an XSS injection,\nhe is given the opportunity to inject HTML and JavaScript code directly into the\napplication. This could lead to accounts being compromised by stealing session cookies or directly \naffect the operation of the target application. \n\nAltough templating engines(razor, twig, jinja, etc) and contextaware applications(Angular, React, etc)\ndo a lot of auto escaping for you. These frameworks should always be validated for effectiveness.\n\n\n Solution:\n\nIn order to prevent XSS injections, all userinput should be escaped or encoded.\nYou could start by sanitizing userinput as soon as it is inserted into the application,\nby preference using a so called whitelisting method.\nThis means you should not check for malicious content like the tags or anything,\nbut only allow the expected input. Every input which is outside of the intended operation\nof the application should immediately be detected and login rejected.\nDo not try to help use the input in any way because that could introduce a new type of attack by converting characters. \n\nThe second step would be encoding all the parameters or userinput before putting this in\nyour html with encoding libraries specially designed for this purpose.\n\nYou should take into consideration that there are several contexts for encoding userinput for\nescaping XSS injections. These contexts are amongst others:\n\n HTML encoding, is for whenever your userinput is displayed directly into your HTML.\n HTML attribute encoding, is the type of encoding/escaping that should be applied \n whenever your user input is displayed into the attribute of your HTML tags.\n HTML URL encoding, this type of encoding/escaping should be applied to whenever you are using userinput into a HREF tag.\n\nJavaScript encoding should be used whenever parameters are rendered via JavaScript; your application will detect normal injections in the first instant. But your application still remains vulnerable to JavaScript encoding which will not be detected by the normal encoding/escaping methods.\n\n", "checklist_items_id": 71, "checklist_items_checklistID": "5.3.3", "checklist_items_content": "Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS.", "checklist_items_type": 1, "include_always": "False", "question_ID": 11, "questions": "Does the sprint implement functions that reflect user supplied input on the side of the client?"}, {"kb_item_id": "46", "kb_item_title": "Prepared statements and query parameterization", "kb_items_content": " Description:\n\nAll SQL queries, HQL, OSQL, NOSQL and stored procedures, related to stored procedures should be\nprotected by the use of query parameterization.\nIf an attacker can inject malicious code into these queries and gain the ability to\nmanipulate them and can withdraw, update and delete data which is stored on the\ntarget database.\n\n Solution:\n\nThe use of prepared statements and parameterized queries is how all developers should\nfirst be taught how to write database queries. They are simple to write, and easier to\nunderstand than dynamic queries. Parameterized queries force the developer to first define\nall the SQL code, and then pass in each parameter to the query later. This coding style\nallows the database to distinguish between code and data, regardless of what user input\nis supplied.\n", "checklist_items_id": 72, "checklist_items_checklistID": "5.3.4", "checklist_items_content": "Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks. (C3)", "checklist_items_type": 1, "include_always": "False", "question_ID": 12, "questions": "Does the sprint implement functions that utilize raw SQL queries?"}, {"kb_item_id": "269", "kb_item_title": "type checking and length checking", "kb_items_content": " Description\n\nType checking, length checking and whitelisting is an essential in defense in depth strategie to make\nyour application more resiliant against input injection attacks.\n\nExample:\n ```\n SELECT FROM pages WHERE id=mysql_real_escape_string($_GET['id'])\n \n \nThis PHP example did effectively not mitigate the SQL injection. This was due to the fact\nthat it only escaped string based SQL injection. \n\nNow, if this application also had additional checks to validate if the value of \nthe $_GET['id'] parameter was indeed as expected an integer and rejected if this condition was false, \nthe attack would effectively been mitigated.\n\n\n Solution\n\nAll the user supplied input that works outside of the intended opteration of the application\nshould be rejected by the application.\n\nSyntax and Semantic Validity\nAn application should check that data is both syntactically and semantically \nvalid (in that order) before using it in any way (including displaying it back to the user). \n\nSyntax validity, means that the data is in the form that is expected. For example, an application\nmay allow a user to select a fourdigit \u201caccount ID\u201d to perform some kind of operation. \nThe application should assume the user is entering a SQL injection payload, and should \ncheck that the data entered by the user is exactly four digits in length, and consists only of numbers \n(in addition to utilizing proper query parameterization).\n\nSemantic validity, includes only accepting input that is within an acceptable range for the\ngiven application functionality and context. For example, a start date must be before an end\ndate when choosing date ranges.\n\n", "checklist_items_id": 73, "checklist_items_checklistID": "5.3.5", "checklist_items_content": "Verify that where parameterized or safer mechanisms are not present, context-specific output encoding is used to protect against injection attacks, such as the use of SQL escaping to protect against SQL injection.", "checklist_items_type": 1, "include_always": "False", "question_ID": 12, "questions": "Does the sprint implement functions that utilize raw SQL queries?"}, {"kb_item_id": "181", "kb_item_title": "Parsing JSON with Javascript", "kb_items_content": " Description:\n\nThe eval() function evaluates or executes an argument.\n\nIf the argument is an expression, eval() evaluates the expression. If the argument is one\nor more JavaScript statements, eval() executes the statements.\n\nThis is exactly the reason why eval() should NEVER be used to parse JSON or other\nformats of data which could possible contain malicious code.\n\n Solution:\n\nFor the purpose of parsing JSON we would recommend the use of the json.parse functionality.\nEven though this function is more trusted you should always build your own security checks\nand encoding routines around the json.parse before mutating the data or passing it on to\na view to be displayed in your HTML.\n", "checklist_items_id": 74, "checklist_items_checklistID": "5.3.6", "checklist_items_content": "Verify that the application projects against JavaScript or JSON injection attacks, including for eval attacks, remote JavaScript includes, CSP bypasses, DOM XSS, and JavaScript expression evaluation.", "checklist_items_type": 1, "include_always": "False", "question_ID": 11, "questions": "Does the sprint implement functions that reflect user supplied input on the side of the client?"}, {"kb_item_id": "11", "kb_item_title": "LDAP injection", "kb_items_content": " Description:\n\nLDAP (Lightweight Directory Access Protocol) Injection is an attack used to exploit web based applications that construct LDAP statements based on user input. When an application fails to properly sanitize user input, it is possible to modify LDAP statements using a local proxy. This could result in the execution of arbitrary commands such as granting permissions to unauthorized queries, and content modification inside the LDAP tree. The same advanced exploitation techniques available in SQL Injection can be similarly applied in LDAP Injection.\n\n Solution:\n\nThe best way to prevent LDAP injection is to use a positive validation scheme for ensuring that the data going into your queries does not contain any attacks. However, in some cases, it is necessary to include special characters in the input that is passed into an LDAP query. In this case, using escaping can prevent the LDAP interpreter from thinking those special characters are actually part of the LDAP query.\n", "checklist_items_id": 75, "checklist_items_checklistID": "5.3.7", "checklist_items_content": "Verify that the application protects against LDAP Injection vulnerabilities, or that specific security controls to prevent LDAP Injection have been implemented. ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))", "checklist_items_type": 1, "include_always": "False", "question_ID": 13, "questions": "Does the sprint implement functions that utilize LDAP?"}, {"kb_item_id": "4", "kb_item_title": "Command injection", "kb_items_content": " Description:\n\nCommand injection is an attack in which the goal is execution of arbitrary commands on\nthe host operating system via a vulnerable application. Command injection attacks are\npossible when an application passes unsafe user supplied data\n(forms, cookies, HTTP headers etc.) to a system shell. In this attack,\nthe attackersupplied operating system commands are usually executed with the privileges\nof the vulnerable application. Command injection attacks are possible largely due to\ninsufficient input validation. This attack differs from Code Injection, in that code\ninjection allows the attacker to adds his own code that is then executed by the application.\nIn Code Injection, the attacker extends the default functionality of the application\nwithout the necessity of executing system commands.\n\n Solution:\n\nUserinput that is used in a shell command should not contain dangerous characters.\nA blacklist of characters is not a good option because it may be difficult to think of\nall of the characters to validate against. A white list containing only allowable\ncharacters should be created to validate the userinput.\n", "checklist_items_id": 76, "checklist_items_checklistID": "5.3.8", "checklist_items_content": "Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))", "checklist_items_type": 1, "include_always": "False", "question_ID": 14, "questions": "Does the sprint implement functions that utilize OS commands?"}, {"kb_item_id": "1", "kb_item_title": "Filename injection Path traversalddddFilename injection Path traversalddddFilename injection Path traversalddddFilename ", "kb_items_content": "dddd Description:\n\nA Path Traversal attack aims to access files and directories that are stored outside the web root folder. By browsing the application, the attacker looks for absolute links to files stored on the web server. By manipulating variables that reference files with dotdotslash (../); sequences and its variations, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and critical system files, limited by system operational access control. The attacker uses ../../ sequences to move up to root directory, thus permitting navigation through the file system. This attack can be executed with an external malicious code injected on the path, like the Resource Injection attack.\n\n\n Solution:\n\nThe most effective solution to eliminate file inclusion vulnerabilities is to avoid passing\nusersubmitted input to any filesystem/framework API. If this is not possible the application\ncan maintain a white list of files, that may be included on the page, and then use an identifier\n(for example the index number) to access the selected file. Any request containing an invalid\nidentifier has to be rejected, in this way there is no attack surface for malicious users to\nmanipulate the path.\n\n", "checklist_items_id": 77, "checklist_items_checklistID": "5.3.9", "checklist_items_content": "Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks.", "checklist_items_type": 1, "include_always": "False", "question_ID": 15, "questions": "Does the sprint implement functions that get/grabs files from the file system?"}, {"kb_item_id": "183", "kb_item_title": "XML attacks", "kb_items_content": " Description:\n\nWhenever you are using XML in your application there are a few possibilities for\ninjections depending on how you are applying XML in your system.\n\nExtensible Markup Language (XML) is a markup language that defines a set of rules for\nencoding documents in a format which is both humanreadable and machinereadable. It is\ndefined by the W3C's XML 1.0 Specification and by several other related specifications,\nall of which are free open standards.\n\n Solution:\n\nItems listed below are recommended to read whenever you are planning to use XML in your\napplication.\n\nRecommended knowledge base items:\n\n XML injection\n External DTD parsing\n XSLT injections\n XPath injections\n XXE injections\n", "checklist_items_id": 78, "checklist_items_checklistID": "5.3.10", "checklist_items_content": "Verify that the application protects against XPath injection or XML injection attacks. ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))", "checklist_items_type": 1, "include_always": "False", "question_ID": 16, "questions": "Does the sprint implement functions that parse or digests XML?"}, {"kb_item_id": "271", "kb_item_title": "Insecure object deserialization", "kb_items_content": " Description:\n\nSerialization is the process of turning some object into a data format that can be restored later. \nPeople often serialize objects in order to save them to storage, or to send as part of communications.\n\nDeserialization is the reverse of that process, taking data structured from some format, and rebuilding it\ninto an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.\n\nHowever, many programming languages offer a native capability for serializing objects. These native formats\nusually offer more features than JSON or XML, including customizability of the serialization process.\n\nUnfortunately, the features of these native deserialization mechanisms can be repurposed for malicious\neffect when operating on untrusted data. Attacks against deserializers have been found to allow denialofservice,\naccess control, and remote code execution (RCE) attacks.\n\n\n Solution:\n\nVerify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering.\n\nA great reduction of risk is achieved by avoiding native (de)serialization formats. By switching to a \npure data format like JSON or XML, you lessen the chance of custom deserialization logic being repurposed \ntowards malicious ends.\n\nMany applications rely on a datatransfer object pattern that involves creating a separate domain of \nobjects for the explicit purpose data transfer. Of course, it's still possible that the application \nwill make security mistakes after a pure data object is parsed.\n\nIf the application knows before deserialization which messages will need to be processed, \nthey could sign them as part of the serialization process. The application could then to \nchoose not to deserialize any message which didn't have an authenticated signature.\n", "checklist_items_id": 79, "checklist_items_checklistID": "5.5.1", "checklist_items_content": "Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering.", "checklist_items_type": 1, "include_always": "False", "question_ID": 18, "questions": "Does the sprint implement functions that deserializes objects (JSON, XML and YAML)"}, {"kb_item_id": "6", "kb_item_title": "XXE injections", "kb_items_content": " Description:\n\nProcessing of an Xml eXternal Entity containing tainted data may lead to the disclosure of\nconfidential information and other system impacts.\nThe XML 1.0 standard defines the structure of an XML document.\nThe standard defines a concept called an entity, which is a storage unit of some type.\n\nThere exists a specific type of entity, an external general parsed entity often shortened\nto an external entity, that can access local or remote content via a declared system\nidentifier and the XML processor may disclose confidential information normally not\naccessible by the application. Attacks can include disclosing local files, which may\ncontain sensitive data such as passwords or private user data.\n\n Solution:\n\nDisable the possibility to fetch resources from an external source.\nThis is normally done in the configuration of the used XML parser.\n", "checklist_items_id": 80, "checklist_items_checklistID": "5.5.2", "checklist_items_content": "Verify that the application correctly restricts XML parsers to only use the most restrictive configuration possible and to ensure that unsafe features such as resolving external entities are disabled to prevent XXE.", "checklist_items_type": 1, "include_always": "False", "question_ID": 18, "questions": "Does the sprint implement functions that deserializes objects (JSON, XML and YAML)"}, {"kb_item_id": "271", "kb_item_title": "Insecure object deserialization", "kb_items_content": " Description:\n\nSerialization is the process of turning some object into a data format that can be restored later. \nPeople often serialize objects in order to save them to storage, or to send as part of communications.\n\nDeserialization is the reverse of that process, taking data structured from some format, and rebuilding it\ninto an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.\n\nHowever, many programming languages offer a native capability for serializing objects. These native formats\nusually offer more features than JSON or XML, including customizability of the serialization process.\n\nUnfortunately, the features of these native deserialization mechanisms can be repurposed for malicious\neffect when operating on untrusted data. Attacks against deserializers have been found to allow denialofservice,\naccess control, and remote code execution (RCE) attacks.\n\n\n Solution:\n\nVerify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering.\n\nA great reduction of risk is achieved by avoiding native (de)serialization formats. By switching to a \npure data format like JSON or XML, you lessen the chance of custom deserialization logic being repurposed \ntowards malicious ends.\n\nMany applications rely on a datatransfer object pattern that involves creating a separate domain of \nobjects for the explicit purpose data transfer. Of course, it's still possible that the application \nwill make security mistakes after a pure data object is parsed.\n\nIf the application knows before deserialization which messages will need to be processed, \nthey could sign them as part of the serialization process. The application could then to \nchoose not to deserialize any message which didn't have an authenticated signature.\n", "checklist_items_id": 81, "checklist_items_checklistID": "5.5.3", "checklist_items_content": "Verify that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries (such as JSON, XML and YAML parsers).", "checklist_items_type": 1, "include_always": "False", "question_ID": 18, "questions": "Does the sprint implement functions that deserializes objects (JSON, XML and YAML)"}, {"kb_item_id": "181", "kb_item_title": "Parsing JSON with Javascript", "kb_items_content": " Description:\n\nThe eval() function evaluates or executes an argument.\n\nIf the argument is an expression, eval() evaluates the expression. If the argument is one\nor more JavaScript statements, eval() executes the statements.\n\nThis is exactly the reason why eval() should NEVER be used to parse JSON or other\nformats of data which could possible contain malicious code.\n\n Solution:\n\nFor the purpose of parsing JSON we would recommend the use of the json.parse functionality.\nEven though this function is more trusted you should always build your own security checks\nand encoding routines around the json.parse before mutating the data or passing it on to\na view to be displayed in your HTML.\n", "checklist_items_id": 82, "checklist_items_checklistID": "5.5.4", "checklist_items_content": "Verify that when parsing JSON in browsers or JavaScript-based backends, JSON.parse is used to parse the JSON document. Do not use eval() to parse JSON.", "checklist_items_type": 1, "include_always": "False", "question_ID": 18, "questions": "Does the sprint implement functions that deserializes objects (JSON, XML and YAML)"}, {"kb_item_id": null, "kb_item_title": null, "kb_items_content": null, "checklist_items_id": 83, "checklist_items_checklistID": "6.0", "checklist_items_content": "Stored Cryptography Verification Requirements", "checklist_items_type": 1, "include_always": "False", "question_ID": 0, "questions": null}, {"kb_item_id": "149", "kb_item_title": "Cryptographic modules must fail securely", "kb_items_content": " Description:\n\nWhenever a cryptographic module does not fail securely this the device needs to be put in\nerror state so it's not useable anymore.\n\n Solution:\n\nWe recommend using the National Institute of Standards and Technology (NIST) standard on testing the cryptographic module making it perform the selftests to see if it fails securely.\n", "checklist_items_id": 84, "checklist_items_checklistID": "6.2.1", "checklist_items_content": "Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks.", "checklist_items_type": 1, "include_always": "False", "question_ID": 19, "questions": "Does the sprint implement functions that process sensitive data?"}, {"kb_item_id": null, "kb_item_title": null, "kb_items_content": null, "checklist_items_id": 85, "checklist_items_checklistID": "7.0", "checklist_items_content": "Error Handling and Logging Verification Requirements", "checklist_items_type": 1, "include_always": "False", "question_ID": 0, "questions": null}, {"kb_item_id": "78", "kb_item_title": "User credentials in audit logs", "kb_items_content": " Description:\n\nWhenever there are user credentials supplied in an audit log,\nthis could become a risk whenever an attacker could gain access to one of these log files.\n\n Solution:\n\nInstead of storing user credentials, you may want to use user ID's in order to\nidentify the user in the log files.\n\n", "checklist_items_id": 86, "checklist_items_checklistID": "7.1.1", "checklist_items_content": "Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form. ([C9, C10](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))", "checklist_items_type": 1, "include_always": "False", "question_ID": 21, "questions": "Does the sprint implement functions that impact logging?"}, {"kb_item_id": "78", "kb_item_title": "User credentials in audit logs", "kb_items_content": " Description:\n\nWhenever there are user credentials supplied in an audit log,\nthis could become a risk whenever an attacker could gain access to one of these log files.\n\n Solution:\n\nInstead of storing user credentials, you may want to use user ID's in order to\nidentify the user in the log files.\n\n", "checklist_items_id": 87, "checklist_items_checklistID": "7.1.2", "checklist_items_content": "Verify that the application does not log other sensitive data as defined under local privacy laws or relevant security policy. ([C9](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))", "checklist_items_type": 1, "include_always": "False", "question_ID": 21, "questions": "Does the sprint implement functions that impact logging?"}, {"kb_item_id": "15", "kb_item_title": "Verbose error messaging", "kb_items_content": " Description:\n\nAn important aspect of secure application development is to prevent information leakage. \nError messages give an attacker great insight into the inner workings of an application.\n\nThe purpose of reviewing the Error Handling code is to assure the application fails safely under all \npossible error conditions, expected and unexpected. No sensitive information is presented to the user \nwhen an error occurs.\n\nWhen an exception or error is thrown we also need to log this occurrence. Sometimes this is due to bad\ndevelopment, but it can be the result of an attack or some other service your application relies on failing.\n\nAll code paths that can cause an exception to be thrown should check for success in order for the exception \nnot to be thrown.\n\n Solution:\n\nWe should use a localized description string in every exception, a friendly error reason such as \u201cSystem Error \u2013 Please try again later\u201d. When the user sees an error message, it will be derived from this description string of the exception that was thrown, and never from the exception class which may contain a stack trace, line number where the error occurred, \nclass name or method name.\n\nDo not expose sensitive information in exception messages. Information such as paths on the local file system is considered privileged information; any system internal information should be hidden from the user. As mentioned before an attacker could use this information to gather private user information from the application or components that make up the app.\n\nDon\u2019t put people\u2019s names or any internal contact information in error messages. Don\u2019t put any \u201chuman\u201d information, which would lead to a level of familiarity and a social engineering exploit.\n\nAnother good example would be for password forget functions to throw a generic error message when a email adress\nis or is not known on the system. This should prevent enumeration of email adresses.\n\n", "checklist_items_id": 88, "checklist_items_checklistID": "7.4.1", "checklist_items_content": "Verify that a generic message is shown when an unexpected or security sensitive error occurs, potentially with a unique ID which support personnel can use to investigate. ([C10](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))", "checklist_items_type": 1, "include_always": "False", "question_ID": 0, "questions": null}, {"kb_item_id": null, "kb_item_title": null, "kb_items_content": null, "checklist_items_id": 89, "checklist_items_checklistID": "8.0", "checklist_items_content": "Error Handling and Logging Verification Requirements", "checklist_items_type": 1, "include_always": "False", "question_ID": 0, "questions": null}, {"kb_item_id": "19", "kb_item_title": "Include anti caching headers", "kb_items_content": " Description:\n\nAnticaching headers have the ability to tell the browser,\ncomputer and proxies what information they may or may not store on the intermediate media\n\n Solution:\n\nThese headers are also known as the: Cachecontrol: nostore,nocache and provide\nprotection of sensitive information when implemented in the application or webserver.\n\nRightly configured anti caching headers will look like the following as a response\n\n\tExpires: Tue, 03 Jul 2001 06:00:00 GMT\n\tLastModified: {now} GMT\n\tCacheControl: nostore, nocache, mustrevalidate, maxage=0\n\tCacheControl: postcheck=0, precheck=0\n\tPragma: nocache\n", "checklist_items_id": 90, "checklist_items_checklistID": "8.2.1", "checklist_items_content": "Verify the application sets sufficient anti-caching headers so that sensitive data is not cached in modern browsers.", "checklist_items_type": 1, "include_always": "False", "question_ID": 25, "questions": "Does the sprint implement functions that store sensitive information?"}, {"kb_item_id": "190", "kb_item_title": "Client side storage", "kb_items_content": " Description:\n\nClient side storage also known as Offline Storage or Web Storage. The Underlying storage mechanism may vary from one\nuser agent to the next. In other words, any authentication your application requires can\nbe bypassed by a user with local privileges to the machine on which the data is stored.\nTherefore, it's recommended not to store any sensitive information in local storage.\n\n Solution:\n\nVerify that authenticated data is cleared from client storage, such as the browser DOM, after the\nsession is terminated. This also goes for other session and local storage information which could\nassist an attacker launching an successful attack.\n\nVerify that data stored in client side storage (such as HTML5 local storage, session storage, IndexedDB, regular\ncookies or Flash cookies) does not contain sensitive data or PII (personal identifiable information).\n\n\n", "checklist_items_id": 91, "checklist_items_checklistID": "8.2.2", "checklist_items_content": "Verify that data stored in client side storage (such as HTML5 local storage, session storage, IndexedDB, regular cookies or Flash cookies) does not contain sensitive data or PII.", "checklist_items_type": 1, "include_always": "False", "question_ID": 25, "questions": "Does the sprint implement functions that store sensitive information?"}, {"kb_item_id": "190", "kb_item_title": "Client side storage", "kb_items_content": " Description:\n\nClient side storage also known as Offline Storage or Web Storage. The Underlying storage mechanism may vary from one\nuser agent to the next. In other words, any authentication your application requires can\nbe bypassed by a user with local privileges to the machine on which the data is stored.\nTherefore, it's recommended not to store any sensitive information in local storage.\n\n Solution:\n\nVerify that authenticated data is cleared from client storage, such as the browser DOM, after the\nsession is terminated. This also goes for other session and local storage information which could\nassist an attacker launching an successful attack.\n\nVerify that data stored in client side storage (such as HTML5 local storage, session storage, IndexedDB, regular\ncookies or Flash cookies) does not contain sensitive data or PII (personal identifiable information).\n\n\n", "checklist_items_id": 92, "checklist_items_checklistID": "8.2.3", "checklist_items_content": "Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated.", "checklist_items_type": 1, "include_always": "False", "question_ID": 25, "questions": "Does the sprint implement functions that store sensitive information?"}, {"kb_item_id": "72", "kb_item_title": "GET POST requests", "kb_items_content": " Description:\n\nAuthors of services which use the HTTP protocol SHOULD NOT use GETbased forms for the\nsubmission of sensitive data, because this will cause this data to be\nencoded in the RequestURI. Many existing servers, proxies,\nand browsers will log the request URL in some place where it might be\nvisible to third parties. Servers can use POSTbased form submission instead.\nGET parameters are also more likely to be vulnerable to XSS. Please refer to the\nXSS manual in the knowledge base for more information.\n\n Solution:\n\nWhenever transmitting sensitive data always do this by means of the POST request or by header.\nNote: Avoid userinput in your application header, this could lead to vulnerabilities.\nAlso make sure you disable all other HTTP request methods which are unnecessary for\nyour applications operation such as; REST, PUT, TRACE, DELETE, OPTIONS, etc, since\nallowing these request methods could lead to vulnerabilities and injections.\n", "checklist_items_id": 93, "checklist_items_checklistID": "8.3.1", "checklist_items_content": "Verify that sensitive data is sent to the server in the HTTP message body or headers, and that query string parameters from any HTTP verb do not contain sensitive data.", "checklist_items_type": 1, "include_always": "False", "question_ID": 25, "questions": "Does the sprint implement functions that store sensitive information?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 94, "checklist_items_checklistID": "8.3.2", "checklist_items_content": "Verify that users have a method to remove or export their data on demand.", "checklist_items_type": 1, "include_always": "False", "question_ID": 25, "questions": "Does the sprint implement functions that store sensitive information?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 95, "checklist_items_checklistID": "8.3.3", "checklist_items_content": "Verify that users are provided clear language regarding collection and use of supplied personal information and that users have provided opt-in consent for the use of that data before it is used in any way.", "checklist_items_type": 1, "include_always": "False", "question_ID": 25, "questions": "Does the sprint implement functions that store sensitive information?"}, {"kb_item_id": "276", "kb_item_title": "Key vault", "kb_items_content": "Description:\n\nKeys should remain in a protected key vault at all times. \nIn particular, ensure that there is a gap between the threat vectors \nthat have direct access to the data and the threat vectors that have direct access to the keys. \nThis implies that keys should not be stored on the application or web server \n(assuming that application attackers are part of the relevant threat model).\n\nA key vault helps secure, store and tightly control access to tokens, passwords, certificates and,\nencryption keys for protecting secrets and other sensitive data. \n\nImagine the use of a keyvault in the following scenario's\n\n* Running a docker container and provisioning it with secrets over CLI\n* Checking in API keys in your source repositories\n* Encrypting sensitive data at rest\n\nVault provides encryption as a service with centralized key management to simplify encrypting data \nin transit and at rest across clouds and datacenters.\n\na Vault can be used to encrypt/decrypt data that is stored elsewhere. The primary use of this is to allow applications to encrypt their data while still storing it in the primary data store.\n\nThe benefit of this is that developers do not need to worry about how to properly encrypt data. The responsibility of encryption is on Vault and the security team managing it, and developers just encrypt/decrypt data as needed.\n\nSolution:\n\ncentrally store, access, and distribute secrets like API keys,\nAWS IAM/STS credentials, SQL/NoSQL databases, X.509 certificates, \nSSH credentials, etc by means of a key vault.\n\nWhen selecting a key vault that is fit for your needs make sure it has Cryptographic Compliance\ntowards the FIPS standards.\n\n\n", "checklist_items_id": 96, "checklist_items_checklistID": "8.3.4", "checklist_items_content": "Verify that all sensitive data created and processed by the application has been identified, and ensure that a policy is in place on how to deal with sensitive data. ([C8](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))", "checklist_items_type": 1, "include_always": "False", "question_ID": 25, "questions": "Does the sprint implement functions that store sensitive information?"}, {"kb_item_id": null, "kb_item_title": null, "kb_items_content": null, "checklist_items_id": 97, "checklist_items_checklistID": "9.0", "checklist_items_content": "Communications Verification Requirements", "checklist_items_type": 1, "include_always": "False", "question_ID": 0, "questions": null}, {"kb_item_id": "244", "kb_item_title": "TLS implementation", "kb_items_content": " Description:\n\nWhenever sensitive information is being sent over the application TLS must be applied in the application\nto prevent malicious attackers eavesdropping the network can look into and manipulate this\nsensitive information.\n\n\n Solution:\n\nVerify that TLS is used for all connections (including both external and backend connections) \nthat are authenticated or that involve sensitive data or functions, and does not fall back to\ninsecure or unencrypted protocols. Ensure the strongest alternative is the preferred algorithm.\n\nAs modern cryptography relies on being computationally expensive to break, specific standards can be set for\nkey sizes that will provide assurance that with today\u2019s technology and understanding, it will take too long\nto decrypt a message by attempting all possible keys.\n\nTherefore, we need to ensure that both the algorithm and the key size are taken into account when selecting\nan algorithm. Whenever computer power increases the standards for selecting a new alogrithm changes as well.\n", "checklist_items_id": 98, "checklist_items_checklistID": "9.1.1", "checklist_items_content": "Verify that secured TLS is used for all client connectivity, and does not fall back to insecure or unencrypted protocols. ([C8](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))", "checklist_items_type": 1, "include_always": "False", "question_ID": 22, "questions": "Does the sprint implement/changes TLS configuration?"}, {"kb_item_id": "247", "kb_item_title": "TLS settings are in line with current leading practice", "kb_items_content": " Description:\n\nTLS settings must always be in line with current leading practice. Whenever TLS\nsettings and ciphers get outdated, the TLS connection can be degraded/broken and used by\nattackers to eavesdrop on users traffic over the application.\n\n Solution:\n\nThere should be structural scans that are done regularly against the applications TLS settings\nand configurations to check whether the TLS settings are in line with current leading practice.\n\nThis could be achieved by using the SSLLabs api or the OWASP OSaft project.\n\nOSaft is an easy to use tool to show informations about SSL certificate and tests the SSL \nconnection according to a given list of ciphers and various SSL configurations.\n\nIt's designed to be used by penetration testers, security auditors or server administrators. \nThe idea is to show the important information or the special checks with a simple call of the tool.\nHowever, it provides a wide range of options so that it can be used for comprehensive and special \nchecks by experienced people.\n\nWhile doing these tests also take into consideration the following configuration on the server\nside:\n\nVerify that old versions of SSL and TLS protocols, algorithms, ciphers, and configuration are \ndisabled, such as SSLv2, SSLv3, or TLS 1.0 and TLS 1.1. The latest version of TLS should be the \npreferred cipher suite.\n\n", "checklist_items_id": 99, "checklist_items_checklistID": "9.1.2", "checklist_items_content": "Verify using online or up to date TLS testing tools that only strong algorithms, ciphers, and protocols are enabled, with the strongest algorithms and ciphers set as preferred.", "checklist_items_type": 1, "include_always": "False", "question_ID": 22, "questions": "Does the sprint implement/changes TLS configuration?"}, {"kb_item_id": "247", "kb_item_title": "TLS settings are in line with current leading practice", "kb_items_content": " Description:\n\nTLS settings must always be in line with current leading practice. Whenever TLS\nsettings and ciphers get outdated, the TLS connection can be degraded/broken and used by\nattackers to eavesdrop on users traffic over the application.\n\n Solution:\n\nThere should be structural scans that are done regularly against the applications TLS settings\nand configurations to check whether the TLS settings are in line with current leading practice.\n\nThis could be achieved by using the SSLLabs api or the OWASP OSaft project.\n\nOSaft is an easy to use tool to show informations about SSL certificate and tests the SSL \nconnection according to a given list of ciphers and various SSL configurations.\n\nIt's designed to be used by penetration testers, security auditors or server administrators. \nThe idea is to show the important information or the special checks with a simple call of the tool.\nHowever, it provides a wide range of options so that it can be used for comprehensive and special \nchecks by experienced people.\n\nWhile doing these tests also take into consideration the following configuration on the server\nside:\n\nVerify that old versions of SSL and TLS protocols, algorithms, ciphers, and configuration are \ndisabled, such as SSLv2, SSLv3, or TLS 1.0 and TLS 1.1. The latest version of TLS should be the \npreferred cipher suite.\n\n", "checklist_items_id": 100, "checklist_items_checklistID": "9.1.3", "checklist_items_content": "Verify that old versions of SSL and TLS protocols, algorithms, ciphers, and configuration are disabled, such as SSLv2, SSLv3, or TLS 1.0 and TLS 1.1. The latest version of TLS should be the preferred cipher suite.", "checklist_items_type": 1, "include_always": "False", "question_ID": 22, "questions": "Does the sprint implement/changes TLS configuration?"}, {"kb_item_id": null, "kb_item_title": null, "kb_items_content": null, "checklist_items_id": 101, "checklist_items_checklistID": "10.0", "checklist_items_content": "Malicious Code Verification Requirements", "checklist_items_type": 1, "include_always": "False", "question_ID": 0, "questions": null}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 102, "checklist_items_checklistID": "10.3.1", "checklist_items_content": "Verify that if the application has a client or server auto-update feature, updates should be obtained over secure channels and digitally signed. The update code must validate the digital signature of the update before installing or executing the update.", "checklist_items_type": 1, "include_always": "False", "question_ID": 1, "questions": "Does the sprint implement changes that affect and change CI/CD?"}, {"kb_item_id": "303", "kb_item_title": "code signing", "kb_items_content": "Description:\nCode signing is the process of digitally signing executables and scripts to confirm the software \nauthor and guarantee that the code has not been altered or corrupted since it was signed. \nThe process employs the use of a cryptographic hash to validate authenticity and integrity.\n\nCode signing can provide several valuable features. The most common use of code signing is to \nprovide security when deploying; in some programming languages, it can also be used to help prevent \nnamespace conflicts. Almost every code signing implementation will provide some sort of digital \nsignature mechanism to verify the identity of the author or build system, and a checksum to verify \nthat the object has not been modified. It can also be used to provide versioning information about an \nobject or to store other meta data about an objec\n\nSolution:\nSign your code and validate the signatures(checksums) of your code and third party\ncomponents to confirm the integrity of the deployed components.\n", "checklist_items_id": 103, "checklist_items_checklistID": "10.3.2", "checklist_items_content": "Verify that the application employs integrity protections, such as code signing or sub-resource integrity. The application must not load or execute code from untrusted sources, such as loading includes, modules, plugins, code, or libraries from untrusted sources or the Internet.", "checklist_items_type": 1, "include_always": "False", "question_ID": 1, "questions": "Does the sprint implement changes that affect and change CI/CD?"}, {"kb_item_id": "294", "kb_item_title": "sub domain take over", "kb_items_content": "Description:\nSubdomain takeover is a process of registering a nonexisting domain name to gain control over another domain. \nThe most common scenario of this process follows:\n\nDomain name (e.g., sub.example.com) uses a CNAME record to another domain (e.g., sub.example.com CNAME anotherdomain.com).\nAt some point in time, anotherdomain.com expires and is available for registration by anyone.\nSince the CNAME record is not deleted from example.com DNS zone, anyone who registers anotherdomain.com has\nfull control over sub.example.com until the DNS record is present.\n\nThe implications of the subdomain takeover can be pretty significant. Using a subdomain takeover, attackers\ncan send phishing emails from the legitimate domain, perform crosssite scripting (XSS), or damage the \nreputation of the brand which is associated with the domain. \n\nSource: https://0xpatrik.com/subdomaintakeoverbasics/\n", "checklist_items_id": 104, "checklist_items_checklistID": "10.3.3", "checklist_items_content": "Verify that the application has protection from sub-domain takeovers if the application relies upon DNS entries or DNS sub-domains, such as expired domain names, out of date DNS pointers or CNAMEs, expired projects at public source code repos, or transient cloud APIs, serverless functions, or storage buckets (autogen-bucket-id.cloud.example.com) or similar. Protections can include ensuring that DNS names used by applications are regularly checked for expiry or change.", "checklist_items_type": 1, "include_always": "False", "question_ID": 1, "questions": "Does the sprint implement changes that affect and change CI/CD?"}, {"kb_item_id": null, "kb_item_title": null, "kb_items_content": null, "checklist_items_id": 105, "checklist_items_checklistID": "11.0", "checklist_items_content": "Business Logic Verification Requirements", "checklist_items_type": 1, "include_always": "False", "question_ID": 0, "questions": null}, {"kb_item_id": "110", "kb_item_title": "Enforce sequential step order", "kb_items_content": " Description:\n\nWhenever a functionality consists out of following several steps to achieve some goal i.e,\n\nUser adds items to chart > User enters shipping information > User pays for goods > Items will be shipped.\nYou want to make sure the user can not skip the payment step in order to receive his goods.\n\n Solution:\n\nIn order to verify that this stage was run through by a sincere user you want to enforce\nthe application to only process business logic flows in sequential step order, with all\nsteps being processed in realistic human time, and not process out of order, skipped steps,\nprocessed steps from another user, or too quickly submitted transactions.\n\n", "checklist_items_id": 106, "checklist_items_checklistID": "11.1.1", "checklist_items_content": "Verify the application will only process business logic flows for the same user in sequential step order and without skipping steps.", "checklist_items_type": 1, "include_always": "False", "question_ID": 30, "questions": "Does this sprint introduce functions with critical business logic that needs to be reviewed?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 107, "checklist_items_checklistID": "11.1.2", "checklist_items_content": "Verify the application will only process business logic flows with all steps being processed in realistic human time, i.e. transactions are not submitted too quickly.", "checklist_items_type": 1, "include_always": "False", "question_ID": 30, "questions": "Does this sprint introduce functions with critical business logic that needs to be reviewed?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 108, "checklist_items_checklistID": "11.1.3", "checklist_items_content": "Verify the application has appropriate limits for specific business actions or transactions which are correctly enforced on a per user basis.", "checklist_items_type": 1, "include_always": "False", "question_ID": 30, "questions": "Does this sprint introduce functions with critical business logic that needs to be reviewed?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 109, "checklist_items_checklistID": "11.1.4", "checklist_items_content": "Verify the application has sufficient anti-automation controls to detect and protect against data exfiltration, excessive business logic requests, excessive file uploads or denial of service attacks.", "checklist_items_type": 1, "include_always": "False", "question_ID": 30, "questions": "Does this sprint introduce functions with critical business logic that needs to be reviewed?"}, {"kb_item_id": "164", "kb_item_title": "Threat modeling", "kb_items_content": " Description:\n\nThreat modeling is a procedure for optimizing Network/ Application/ Internet Security by\nidentifying objectives and vulnerabilities, and then defining countermeasures to prevent,\nor mitigate the effects of, threats to the system. A threat is a potential or actual\nundesirable event that may be malicious (such as DoS attack) or incidental\n(failure of a Storage Device). Threat modeling is a planned activity for identifying and\nassessing application threats and vulnerabilities.\n\n Solution:\n\nThreat modeling is best applied continuously throughout a software development project.\nThe process is essentially the same at different levels of abstraction, although the\ninformation gets more and more granular throughout the lifecycle. Ideally, a highlevel\nthreat model should be defined in the concept or planning phase, and then refined\nthroughout the lifecycle. As more details are added to the system, new attack vectors are\ncreated and exposed. The ongoing threat modeling process should examine, diagnose, and\naddress these threats.\n\nNote that it is a natural part of refining a system for new threats to be exposed.\nFor example, when you select a particular technology such as Java for example \nyou take on the responsibility to identify the new threats that are created by that choice.\nEven implementation choices such as using regular expressions for validation introduce\npotential new threats to deal with.\n\nMore indepth information about threat modeling can be found at:\nhttps://www.owasp.org/index.php/Application_Threat_Modeling\n", "checklist_items_id": 110, "checklist_items_checklistID": "11.1.5", "checklist_items_content": "Verify the application has business logic limits or validation to protect against likely business risks or threats, identified using threat modelling or similar methodologies.", "checklist_items_type": 1, "include_always": "True", "question_ID": 30, "questions": "Does this sprint introduce functions with critical business logic that needs to be reviewed?"}, {"kb_item_id": "293", "kb_item_title": "race conditions", "kb_items_content": "Description:\nA race condition is a flaw that produces an unexpected result when the timing of actions impact other actions. \nAn example may be seen on a multithreaded application where actions are being performed on the same data. \nRace conditions, by their very nature, are difficult to test for.\n\nRace conditions may occur when a process is critically or unexpectedly dependent on the sequence or timings of \nother events. In a web application environment, where multiple requests can be processed at a given time, \ndevelopers may leave concurrency to be handled by the framework, server, or programming language.\n\nSolution:\n\nOne common solution to prevent race conditions is known as locking. This ensures that at any given time, \nat most one thread can modify the database. Many databases provide functionality to lock a given row when a \nthread is accessing it.\n\n", "checklist_items_id": 111, "checklist_items_checklistID": "11.1.6", "checklist_items_content": "Verify the application does not suffer from \"time of check to time of use\" (TOCTOU) issues or other race conditions for sensitive operations.", "checklist_items_type": 1, "include_always": "True", "question_ID": 30, "questions": "Does this sprint introduce functions with critical business logic that needs to be reviewed?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 112, "checklist_items_checklistID": "11.1.8", "checklist_items_content": "Verify the application has configurable alerting when automated attacks or unusual activity is detected.", "checklist_items_type": 1, "include_always": "False", "question_ID": 30, "questions": "Does this sprint introduce functions with critical business logic that needs to be reviewed?"}, {"kb_item_id": null, "kb_item_title": null, "kb_items_content": null, "checklist_items_id": 113, "checklist_items_checklistID": "12.0", "checklist_items_content": "File and Resources Verification Requirements", "checklist_items_type": 1, "include_always": "False", "question_ID": 0, "questions": null}, {"kb_item_id": "13", "kb_item_title": "File upload injections", "kb_items_content": " Description:\n\nUploaded files represent a significant risk to applications.\nThe first step in many attacks is to get some code to the system to be attacked.\nThen the attack only needs to find a way to get the code executed. Using a file upload\nhelps the attacker accomplish the first step.\n\nThe consequences of unrestricted file upload can vary, including complete system takeover,\nan overloaded file system or database, forwarding attacks to backend systems, and simple\ndefacement.\n\nThere are really two classes of problems here.\nThe first is with the file metadata, like the path and file name.\nThese are generally provided by the transport, such as HTTP multipart encoding.\nThis data may trick the application into overwriting a critical file or storing the file\nin a bad location. You must validate the metadata extremely carefully before using it.\n\nThe other class of problem is with the file size or content.\nAn attacker can easily craft a valid image file with PHP code inside.\n\n Solution:\n\n Uploaded files always need to be placed outside the document root of the webserver\n Check to not accept large files that could fill up storage or cause a denial of service attack\n Check the userinput(filename) for having the right allowed extensions such as .jpg, .png etc\n Note: when checking these extensions always make sure your application validates the last\n possible extension so an attacker could not simply inject \".jpg.php\" and bypass your\n validation\n\n Check the userinput(filename) for containing possible path traversal patterns in order to prevent him from uploading outside of the intended directory.\n\nYou may also want to check if the filenames do already exist before uploading in order to\nprevent the overwriting of files.\n\nAlso for serving the files back there needs to be a file handler function that can select\nthe file based on an identifier that will serve the file back towards the user.\n\nMost developers also do a mimetype check. This is a good protection however not\nwhenever you are checking this mimetype through the post request. This header can not be\ntrusted since it can be easily manipulated by an attacker.\n\nThe best way to check the mimetype\nis to extract the file from the server after uploading and check it from the file itself.\nDeleting it whenever it does not comply with expected values.\n\n", "checklist_items_id": 114, "checklist_items_checklistID": "12.1.1", "checklist_items_content": "Verify that the application will not accept large files that could fill up storage or cause a denial of service attack.", "checklist_items_type": 1, "include_always": "False", "question_ID": 23, "questions": "Does the sprint implement functions that allow users to upload/download files?"}, {"kb_item_id": "13", "kb_item_title": "File upload injections", "kb_items_content": " Description:\n\nUploaded files represent a significant risk to applications.\nThe first step in many attacks is to get some code to the system to be attacked.\nThen the attack only needs to find a way to get the code executed. Using a file upload\nhelps the attacker accomplish the first step.\n\nThe consequences of unrestricted file upload can vary, including complete system takeover,\nan overloaded file system or database, forwarding attacks to backend systems, and simple\ndefacement.\n\nThere are really two classes of problems here.\nThe first is with the file metadata, like the path and file name.\nThese are generally provided by the transport, such as HTTP multipart encoding.\nThis data may trick the application into overwriting a critical file or storing the file\nin a bad location. You must validate the metadata extremely carefully before using it.\n\nThe other class of problem is with the file size or content.\nAn attacker can easily craft a valid image file with PHP code inside.\n\n Solution:\n\n Uploaded files always need to be placed outside the document root of the webserver\n Check to not accept large files that could fill up storage or cause a denial of service attack\n Check the userinput(filename) for having the right allowed extensions such as .jpg, .png etc\n Note: when checking these extensions always make sure your application validates the last\n possible extension so an attacker could not simply inject \".jpg.php\" and bypass your\n validation\n\n Check the userinput(filename) for containing possible path traversal patterns in order to prevent him from uploading outside of the intended directory.\n\nYou may also want to check if the filenames do already exist before uploading in order to\nprevent the overwriting of files.\n\nAlso for serving the files back there needs to be a file handler function that can select\nthe file based on an identifier that will serve the file back towards the user.\n\nMost developers also do a mimetype check. This is a good protection however not\nwhenever you are checking this mimetype through the post request. This header can not be\ntrusted since it can be easily manipulated by an attacker.\n\nThe best way to check the mimetype\nis to extract the file from the server after uploading and check it from the file itself.\nDeleting it whenever it does not comply with expected values.\n\n", "checklist_items_id": 115, "checklist_items_checklistID": "12.3.1", "checklist_items_content": "Verify that user-submitted filename metadata is not used directly with system or framework file and URL API to protect against path traversal.", "checklist_items_type": 1, "include_always": "False", "question_ID": 23, "questions": "Does the sprint implement functions that allow users to upload/download files?"}, {"kb_item_id": "13", "kb_item_title": "File upload injections", "kb_items_content": " Description:\n\nUploaded files represent a significant risk to applications.\nThe first step in many attacks is to get some code to the system to be attacked.\nThen the attack only needs to find a way to get the code executed. Using a file upload\nhelps the attacker accomplish the first step.\n\nThe consequences of unrestricted file upload can vary, including complete system takeover,\nan overloaded file system or database, forwarding attacks to backend systems, and simple\ndefacement.\n\nThere are really two classes of problems here.\nThe first is with the file metadata, like the path and file name.\nThese are generally provided by the transport, such as HTTP multipart encoding.\nThis data may trick the application into overwriting a critical file or storing the file\nin a bad location. You must validate the metadata extremely carefully before using it.\n\nThe other class of problem is with the file size or content.\nAn attacker can easily craft a valid image file with PHP code inside.\n\n Solution:\n\n Uploaded files always need to be placed outside the document root of the webserver\n Check to not accept large files that could fill up storage or cause a denial of service attack\n Check the userinput(filename) for having the right allowed extensions such as .jpg, .png etc\n Note: when checking these extensions always make sure your application validates the last\n possible extension so an attacker could not simply inject \".jpg.php\" and bypass your\n validation\n\n Check the userinput(filename) for containing possible path traversal patterns in order to prevent him from uploading outside of the intended directory.\n\nYou may also want to check if the filenames do already exist before uploading in order to\nprevent the overwriting of files.\n\nAlso for serving the files back there needs to be a file handler function that can select\nthe file based on an identifier that will serve the file back towards the user.\n\nMost developers also do a mimetype check. This is a good protection however not\nwhenever you are checking this mimetype through the post request. This header can not be\ntrusted since it can be easily manipulated by an attacker.\n\nThe best way to check the mimetype\nis to extract the file from the server after uploading and check it from the file itself.\nDeleting it whenever it does not comply with expected values.\n\n", "checklist_items_id": 116, "checklist_items_checklistID": "12.3.2", "checklist_items_content": "Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure, creation, updating or removal of local files (LFI).", "checklist_items_type": 1, "include_always": "False", "question_ID": 23, "questions": "Does the sprint implement functions that allow users to upload/download files?"}, {"kb_item_id": "13", "kb_item_title": "File upload injections", "kb_items_content": " Description:\n\nUploaded files represent a significant risk to applications.\nThe first step in many attacks is to get some code to the system to be attacked.\nThen the attack only needs to find a way to get the code executed. Using a file upload\nhelps the attacker accomplish the first step.\n\nThe consequences of unrestricted file upload can vary, including complete system takeover,\nan overloaded file system or database, forwarding attacks to backend systems, and simple\ndefacement.\n\nThere are really two classes of problems here.\nThe first is with the file metadata, like the path and file name.\nThese are generally provided by the transport, such as HTTP multipart encoding.\nThis data may trick the application into overwriting a critical file or storing the file\nin a bad location. You must validate the metadata extremely carefully before using it.\n\nThe other class of problem is with the file size or content.\nAn attacker can easily craft a valid image file with PHP code inside.\n\n Solution:\n\n Uploaded files always need to be placed outside the document root of the webserver\n Check to not accept large files that could fill up storage or cause a denial of service attack\n Check the userinput(filename) for having the right allowed extensions such as .jpg, .png etc\n Note: when checking these extensions always make sure your application validates the last\n possible extension so an attacker could not simply inject \".jpg.php\" and bypass your\n validation\n\n Check the userinput(filename) for containing possible path traversal patterns in order to prevent him from uploading outside of the intended directory.\n\nYou may also want to check if the filenames do already exist before uploading in order to\nprevent the overwriting of files.\n\nAlso for serving the files back there needs to be a file handler function that can select\nthe file based on an identifier that will serve the file back towards the user.\n\nMost developers also do a mimetype check. This is a good protection however not\nwhenever you are checking this mimetype through the post request. This header can not be\ntrusted since it can be easily manipulated by an attacker.\n\nThe best way to check the mimetype\nis to extract the file from the server after uploading and check it from the file itself.\nDeleting it whenever it does not comply with expected values.\n\n", "checklist_items_id": 117, "checklist_items_checklistID": "12.3.3", "checklist_items_content": "Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure or execution of remote files (RFI); which may also lead to SSRF.", "checklist_items_type": 1, "include_always": "False", "question_ID": 23, "questions": "Does the sprint implement functions that allow users to upload/download files?"}, {"kb_item_id": "160", "kb_item_title": "RFD and file download injections", "kb_items_content": " Description:\n\nReflective file download occurs whenever an attacker can \"forge\" a download through misconfiguration in your \"disposition\" and \"content type\" headers. Instead of having the attacker to upload an evil file to the web server he can now force the browser to download a malicious file by abusing these headers and setting the file extension to any type he wants.\n\nNow, whenever there is also userinput being reflected back into that download it can be used to forge evil attacks. The attacker can present an evil file to ignorant victim's who are trusting the domain of which the download was presented from.\n\nFile download injection is a similar type of attack except this attack is made possible whenever there is userinput that is reflected into the \"filename=\" parameter in the \"disposition\" header. The attacker again can force the browser to download a file with his own choice of extension and set the content of this file by injecting this directly into the response like filename=evil.bat%0A%0D%0A%0DinsertEvilStringHere\n\nWhenever the user now opens the downloaded file the attacker can gain full control over the target\u2019s device.\n\n\n Solution:\n\nFirst, never use user input directly into your headers since an attacker can now take control over it.\n\nSecondly, you should check if a filename really does exist before presenting it towards the users. You could also create a whitelist of all files which are allowed to be downloaded and terminate requests whenever they do not match.\n\nAlso, you should disable the use of \"path parameters\". It increases the attacker\u2019s attack vector and these parameters also cause a lot of other vulnerabilities.\nAnd last you should sanitize and encode all your userinput as much as possible. Reflective file downloads depend on userinput being reflected in the response header. Whenever this input has been sanitized and encoded it should not do any harm to any system it is being executed on\n\n", "checklist_items_id": 118, "checklist_items_checklistID": "12.3.4", "checklist_items_content": "Verify that the application protects against reflective file download (RFD) by validating or ignoring user-submitted filenames in a JSON, JSONP, or URL parameter, the response Content-Type header should be set to text/plain, and the Content-Disposition header should have a fixed filename.", "checklist_items_type": 1, "include_always": "False", "question_ID": 23, "questions": "Does the sprint implement functions that allow users to upload/download files?"}, {"kb_item_id": "225", "kb_item_title": "File IO commands", "kb_items_content": " Description:\n\nI/O commands allow you to own, use, read from, write to, close devices and To direct I/O \noperations to a device. Whenever user supplied input i.e file names and/or file data is being \ndirectly used in these commands, this could lead to path traversal, local file include, file \nmime type, and OS command injection vulnerabilities.\n\n Solution:\n\nFile names and file contents should be sanitized before being used in I/O commands. \n", "checklist_items_id": 119, "checklist_items_checklistID": "12.3.5", "checklist_items_content": "Verify that untrusted file metadata is not used directly with system API or libraries, to protect against OS command injection.", "checklist_items_type": 1, "include_always": "False", "question_ID": 23, "questions": "Does the sprint implement functions that allow users to upload/download files?"}, {"kb_item_id": "227", "kb_item_title": "File upload outside document root", "kb_items_content": " Description:\n\nFiles that are uploaded by users or other untrusted services should always be placed outside\nof the document root. This is to prevent malicious files from being parsed by attackers such as PHP/HTML/Javascript files.\n\nShould an attacker succeed to bypass file upload restrictions and upload a malicous file, it would\nbe impossible for the attacker to parse these files since they are not located inside of the\napplications document root.\n\n Solution:\n\nFiles should be stored outside of the applications document root. Preferably files should be stored\non a seperate file server which serves back and forth to the application server. \n\nFiles should always be stored outside of the scope of the attacker to prevent files from\nbeing parsed or executed.\n\nWhen storing files outside of the document root, take into consideration potential path traversal injections\nin the applications file name such as \"../html/backtoroot/file.php\". Whenever this filename is being used directly\ninto the path that is used to store files, it could be used to manipulate the storage path.\n", "checklist_items_id": 120, "checklist_items_checklistID": "12.4.1", "checklist_items_content": "Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions, preferably with strong validation.", "checklist_items_type": 1, "include_always": "False", "question_ID": 23, "questions": "Does the sprint implement functions that allow users to upload/download files?"}, {"kb_item_id": "226", "kb_item_title": "File upload anti virus check", "kb_items_content": " Description:\n\nwhenever files from untrusted services are uploaded to the server, there should be additional checks\nin place to verify whether these files contain viruses (malware, trojans, ransomware). \n\n Solution:\n\nAfter uploading the file, the file should be placed in quarantine and antivirus has to \ninspect the file for malicious viruses. Antivirus software that has a commandline interface is \nrequisite for doing such scans. There are also API's available for other services such as\nfrom \"VirusTotal.com\" \n\nThis site provides a free service in which your file is given as input to \nnumerous antivirus products and you receive back a detailed report with the evidence resulting from \nthe scanning process\n", "checklist_items_id": 121, "checklist_items_checklistID": "12.4.2", "checklist_items_content": "Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload of known malicious content.", "checklist_items_type": 1, "include_always": "False", "question_ID": 23, "questions": "Does the sprint implement functions that allow users to upload/download files?"}, {"kb_item_id": "288", "kb_item_title": "Serve files whitelist.", "kb_items_content": "Description:\n\nConfigiring the web server to only serve files with an expected\nfile extension helps prevent information leakage whenever developers\nforget to remove backup files or zipped versions of the web application\nfrom the webserver.\n\n\nSolution:\n\nVerify that the web tier is configured to serve only files with specific\nfile extensions to prevent unintentional information and source\ncode leakage. For example, backup files (e.g. .bak), temporary working\nfiles (e.g. .swp), compressed files (.zip, .tar.gz, etc) and other extensions\ncommonly used by editors should be blocked unless required.\n", "checklist_items_id": 122, "checklist_items_checklistID": "12.5.1", "checklist_items_content": "Verify that the web tier is configured to serve only files with specific file extensions to prevent unintentional information and source code leakage. For example, backup files (e.g. .bak); temporary working files (e.g. .swp); compressed files (.zip, .tar.gz, etc) and other extensions commonly used by editors should be blocked unless required.", "checklist_items_type": 1, "include_always": "False", "question_ID": 23, "questions": "Does the sprint implement functions that allow users to upload/download files?"}, {"kb_item_id": "227", "kb_item_title": "File upload outside document root", "kb_items_content": " Description:\n\nFiles that are uploaded by users or other untrusted services should always be placed outside\nof the document root. This is to prevent malicious files from being parsed by attackers such as PHP/HTML/Javascript files.\n\nShould an attacker succeed to bypass file upload restrictions and upload a malicous file, it would\nbe impossible for the attacker to parse these files since they are not located inside of the\napplications document root.\n\n Solution:\n\nFiles should be stored outside of the applications document root. Preferably files should be stored\non a seperate file server which serves back and forth to the application server. \n\nFiles should always be stored outside of the scope of the attacker to prevent files from\nbeing parsed or executed.\n\nWhen storing files outside of the document root, take into consideration potential path traversal injections\nin the applications file name such as \"../html/backtoroot/file.php\". Whenever this filename is being used directly\ninto the path that is used to store files, it could be used to manipulate the storage path.\n", "checklist_items_id": 123, "checklist_items_checklistID": "12.5.2", "checklist_items_content": "Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content.", "checklist_items_type": 1, "include_always": "False", "question_ID": 23, "questions": "Does the sprint implement functions that allow users to upload/download files?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 124, "checklist_items_checklistID": "12.6.1", "checklist_items_content": "Verify that the web or application server is configured with a whitelist of resources or systems to which the server can send requests or load data/files from.", "checklist_items_type": 1, "include_always": "False", "question_ID": 23, "questions": "Does the sprint implement functions that allow users to upload/download files?"}, {"kb_item_id": null, "kb_item_title": null, "kb_items_content": null, "checklist_items_id": 125, "checklist_items_checklistID": "13.0", "checklist_items_content": "API and Web Service Verification Requirements", "checklist_items_type": 1, "include_always": "False", "question_ID": 0, "questions": null}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 126, "checklist_items_checklistID": "13.1.1", "checklist_items_content": "Verify that all application components use the same encodings and parsers to avoid parsing attacks that exploit different URI or file parsing behavior that could be used in SSRF and RFI attacks.", "checklist_items_type": 1, "include_always": "False", "question_ID": 29, "questions": "Are you building on an application that has API features?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 127, "checklist_items_checklistID": "13.1.2", "checklist_items_content": "Verify that access to administration and management functions is limited to authorized administrators.", "checklist_items_type": 1, "include_always": "False", "question_ID": 29, "questions": "Are you building on an application that has API features?"}, {"kb_item_id": "91", "kb_item_title": "Verify that the sensitive information is never disclosed", "kb_items_content": " Description:\n\nInformation exposure through query strings in URL is when sensitive data is passed to parameters in the URL. This allows attackers to obtain sensitive data such as usernames, passwords, tokens (authX), database details, and any other potentially sensitive data. Simply using HTTPS does not resolve this vulnerability.\n\nRegardless of using encryption, the following URL will expose information in the locations detailed below: https://vulnerablehost.com/authuser?user=bob&authz_token=1234&expire=1500000000\n\nThe parameter values for 'user', 'authz_token', and 'expire' will be exposed in the following locations \nwhen using HTTP or HTTPS:\n\n Referer Header\n Web Logs\n Shared Systems\n Browser History\n Browser Cache\n Shoulder Surfing\n\nWhen not using an encrypted channel, all of the above and the following:\n ManintheMiddle\n\n\n Solution:\n\nSensitive informtion should never be included in the URL.\n", "checklist_items_id": 128, "checklist_items_checklistID": "13.1.3", "checklist_items_content": "Verify API URLs do not expose sensitive information, such as the API key, session tokens etc.", "checklist_items_type": 1, "include_always": "False", "question_ID": 29, "questions": "Are you building on an application that has API features?"}, {"kb_item_id": "129", "kb_item_title": "HTTP request methods", "kb_items_content": " Description:\n\nHTTP offers a number of methods that can be used to perform actions on the web server.\nMany of these methods are designed to aid developers in deploying and testing\nHTTP applications. These HTTP methods can be used for nefarious purposes if the web\nserver is misconfigured. It recommended to read about the different available methods, their purposes and\nlimitations.\n\nAvailable method are:\n\nGET\nThe GET method requests a representation of the specified resource. Requests using GET should only retrieve data and should have no other effect. (This is also true of some other HTTP methods.)[1] The W3C has published guidance principles on this distinction, saying, \"Web application design should be informed by the above principles, but also by the relevant limitations.\n\nHEAD\nThe HEAD method asks for a response identical to that of a GET request, but without the response body. This is useful for retrieving metainformation written in response headers, without having to transport the entire content.\n\nPOST\nThe POST method requests that the server accept the entity enclosed in the request as a new subordinate of the web resource identified by the URI. The data POSTed might be, for example, an annotation for existing resources; a message for a bulletin board, newsgroup, mailing list, or comment thread; a block of data that is the result of submitting a web form to a datahandling process; or an item to add to a database.\n\n\nPUT\nThe PUT method requests that the enclosed entity be stored under the supplied URI. If the URI refers to an already existing resource, it is modified; if the URI does not point to an existing resource, then the server can create the resource with that URI.\n\n\nDELETE\nThe DELETE method deletes the specified resource.\n\n\nTRACE\nThe TRACE method echoes the received request so that a client can see what (if any) changes or additions have been made by intermediate servers.\n\nOPTIONS\nThe OPTIONS method returns the HTTP methods that the server supports for the specified URL. This can be used to check the functionality of a web server by requesting '*' instead of a specific resource.\n\nCONNECT\nThe CONNECT method converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSLencrypted communication (HTTPS) through an unencrypted HTTP proxy.\n\nPATCH\nThe PATCH method applies partial modifications to a resource.\n\nSome of the methods (for example, GET, HEAD, OPTIONS and TRACE) are, by convention, defined as safe, which means they are intended only for information retrieval and should not change the state of the server. In other words, they should not have side effects, beyond relatively harmless effects such as logging, web caching, the serving of banner advertisements or incrementing a web counter. Making arbitrary GET requests without regard to the context of the application's state should therefore be considered safe. However, this is not mandated by the standard, and it is explicitly acknowledged that it cannot be guaranteed.\n\nDespite the prescribed safety of GET requests, in practice their handling by the server is not technically limited in any way. Therefore, careless or deliberate programming can cause nontrivial changes on the server. This is discouraged, because it can cause problems for web caching, search engines and other automated agents, which can make unintended changes on the server. For example, a website might allow deletion of a resource through a URL such as http://example.com/article/1234/delete, which, if arbitrarily fetched, even using GET, would simply delete the article.\n\nBy contrast, methods such as POST, PUT, DELETE and PATCH are intended for actions that may cause side effects either on the server, or external side effects such as financial transactions or transmission of email. Such methods are therefore not usually used by conforming web robots or web crawlers; some that do not conform tend to make requests without regard to context or consequences.\n\nMethods PUT and DELETE are defined to be idempotent, meaning that multiple identical requests should have the same effect as a single request (note that idempotence refers to the state of the system after the request has completed, so while the action the server takes (e.g. deleting a record) or the response code it returns may be different on subsequent requests, the system state will be the same every time). Methods GET, HEAD, OPTIONS and TRACE, being prescribed as safe, should also be idempotent, as HTTP is a stateless protocol.\n\nIn contrast, the POST method is not necessarily idempotent, and therefore sending an identical POST request multiple times may further affect state or cause further side effects (such as financial transactions). In some cases this may be desirable, but in other cases this could be due to an accident, such as when a user does not realize that their action will result in sending another request, or they did not receive adequate feedback that their first request was successful. While web browsers may show alert dialog boxes to warn users in some cases where reloading a page may resubmit a POST request, it is generally up to the web application to handle cases where a POST request should not be submitted more than once.\n\nNote that whether a method is idempotent is not enforced by the protocol or web server. It is perfectly possible to write a web application in which (for example) a database insert or other nonidempotent action is triggered by a GET or other request. Ignoring this recommendation, however, may result in undesirable consequences, if a user agent assumes that repeating the same request is safe when it is not.\n\nThe TRACE method can be used as part of a class of attacks known as crosssite tracing; for that reason, common security advice is for it to be disabled in the server configuration. Microsoft IIS supports a proprietary \"TRACK\" method, which behaves similarly, and which is likewise recommended to be disabled\n\n Solution:\n\nVerify that the application accepts only a defined set of HTTP request methods, such as\nGET and POST and unused methods are explicitly blocked/disabled.\n", "checklist_items_id": 129, "checklist_items_checklistID": "13.2.1", "checklist_items_content": "Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT on protected API or resources.", "checklist_items_type": 1, "include_always": "False", "question_ID": 29, "questions": "Are you building on an application that has API features?"}, {"kb_item_id": "286", "kb_item_title": "JSON validation schema", "kb_items_content": "Description:\n\nJSON Schema is a vocabulary that allows you to annotate and validate JSON documents.\n\nWhen adding schema's to your or JSON files you have better control over what\ntype of userinput can be supplied in your application. \nThis dramatically decreases an attacker\u2019s vector when implemented the right way. \nNonetheless, you should always apply your own input validation and rejection\nas an extra layer of defense. This approach is also desirable since you also \nwant to do countering and logging on the user\u2019s requests and input.\n\nSolution:\n\nVerify that JSON schema validation takes place to ensure a properly formed\nJSON request, followed by validation of each input field before any \nprocessing of that data takes place.\n", "checklist_items_id": 130, "checklist_items_checklistID": "13.2.2", "checklist_items_content": "Verify that JSON schema validation is in place and verified before accepting input.", "checklist_items_type": 1, "include_always": "False", "question_ID": 29, "questions": "Are you building on an application that has API features?"}, {"kb_item_id": "224", "kb_item_title": "CSRF on REST", "kb_items_content": " Description:\n\nCrossSite Request Forgery (CSRF) is a type of attack that occurs when a malicious Web site,\nemail, blog, instant message, or program causes a users Web browser to perform an unwanted\naction on a trusted site for which the user is currently authenticated.\n\nThe impact of a successful crosssite request forgery attack is limited to the\ncapabilities exposed by the vulnerable application. For example, this attack could result\nin a transfer of funds, changing a password, or purchasing an item in the users context.\nIn effect, CSRF attacks are used by an attacker to make a target system perform a\nfunction (funds Transfer, form submission etc.) via the targets browser without\nknowledge of the target user at least until the unauthorized function has been committed.\n\n Solution:\n\nREST (REpresentational State Transfer) is a simple stateless architecture that generally runs\nover HTTPS/TLS. The REST style emphasizes that interactions between clients and services are\nenhanced by having a limited number of operations\n\nSince the architecture is stateless, the application should make use of sessions or cookies to\nstore the HTTP sessions, which allow associating information with individual visitors. The preferred method for REST\nservices is to utilize tokens for interactive information interchange between the user and the server. \n\nBy sending this information solely by means of headers, the application is no longer susceptible to CSRF attacks\nsince the CSRF attack utilizes the browsers cookie jar for succesful attacks.\n", "checklist_items_id": 131, "checklist_items_checklistID": "13.2.3", "checklist_items_content": "Verify that RESTful web services that utilize cookies are protected from Cross-Site Request Forgery via the use of at least one or more of the following: triple or double submit cookie pattern (see [references](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet)); CSRF nonces, or ORIGIN request header checks.", "checklist_items_type": 1, "include_always": "False", "question_ID": 29, "questions": "Are you building on an application that has API features?"}, {"kb_item_id": "175", "kb_item_title": "XML schema (XSD)", "kb_items_content": " Description:\n\nWhen adding schema's to your or XML files you have better control over what type of userinput can be supplied in your application. This dramatically decreases an attacker\u2019s vector when implemented the right way. Nonetheless, you should always apply your own input validation and rejection as an extra layer of defense. This approach is also desirable since you also want to do countering and logging on the user\u2019s requests and input.\t \n\n Solution:\n\nVerify that XSD schema validation takes place to ensure a properly formed XML document, followed by validation of each input field before any processing of that data takes place.\n\n", "checklist_items_id": 132, "checklist_items_checklistID": "13.3.1", "checklist_items_content": "Verify that XSD schema validation takes place to ensure a properly formed XML document, followed by validation of each input field before any processing of that data takes place.", "checklist_items_type": 1, "include_always": "False", "question_ID": 29, "questions": "Are you building on an application that has API features?"}, {"kb_item_id": "195", "kb_item_title": "Signed message payloads WS security", "kb_items_content": " Description:\n\nIn order to establish trust between two communicating party's such as servers and clients\nthere message payload should be signed by means of public/private key method. This builds trust\nand makes it harder for attackers to impersonate different users.\n\nWeb Services Security (WSSecurity, WSS) is an extension to SOAP to apply security to \nWeb services. It is a member of the Web service specifications and was published by OASIS.\n\nThe protocol specifies how integrity and confidentiality can be enforced on messages and allows \nthe communication of various security token formats, such as Security Assertion Markup Language (SAML), \nKerberos, and X.509. Its main focus is the use of XML Signature and XML Encryption to provide endtoend security.\n\n Solution:\n\nWSSecurity describes three main mechanisms:\n\nHow to sign SOAP messages to assure integrity. Signed messages also provide nonrepudiation.\nHow to encrypt SOAP messages to assure confidentiality.\nHow to attach security tokens to ascertain the sender's identity.\nThe specification allows a variety of signature formats, encryption algorithms and multiple trust domains, and is open to various security token models, such as:\n\nX.509 certificates,\nKerberos tickets,\nUser ID/Password credentials,\nSAML Assertions, and\ncustomdefined tokens.\nThe token formats and semantics are defined in the associated profile documents.\n\nWSSecurity incorporates security features in the header of a SOAP message, working in the application layer.\n\nThese mechanisms by themselves do not provide a complete security solution for Web services. Instead, this specification is a building block that can be used in conjunction with other Web service extensions and higherlevel applicationspecific protocols to accommodate a wide variety of security models and security technologies. In general, WSS by itself does not provide any guarantee of security. When implementing and using the framework and syntax, it is up to the implementor to ensure that the result is not vulnerable.\n\nKey management, trust bootstrapping, federation and agreement on the technical details (ciphers, formats, algorithms) is outside the scope of WSSecurity.\n\n Use cases:\n\nEndtoend security\nIf a SOAP intermediary is required, and the intermediary is not more or less trusted, messages need to be signed and optionally encrypted. This might be the case of an applicationlevel proxy at a network perimeter that will terminate TCP (transmission control protocol) connections.\n\nNonrepudiation\nOne method for nonrepudiation is to write transactions to an audit trail that is subject to specific security safeguards. Digital signatures, which WSSecurity supports, provide a more direct and verifiable nonrepudiation proof.\n\nAlternative transport bindings\nAlthough almost all SOAP services implement HTTP bindings, in theory other bindings such as JMS or SMTP could be used; in this case endtoend security would be required.\n\nReverse proxy/common security token\nEven if the web service relies upon transport layer security, it might be required for the service to know about the end user, if the service is relayed by a (HTTP) reverse proxy. A WSS header could be used to convey the end user's token, vouched for by the reverse proxy.\n\n\n", "checklist_items_id": 133, "checklist_items_checklistID": "13.3.2", "checklist_items_content": "Verify that the message payload is signed using WS-Security to ensure reliable transport between client and service.", "checklist_items_type": 1, "include_always": "False", "question_ID": 29, "questions": "Are you building on an application that has API features?"}, {"kb_item_id": null, "kb_item_title": null, "kb_items_content": null, "checklist_items_id": 134, "checklist_items_checklistID": "14.0", "checklist_items_content": "Configuration Verification Requirements", "checklist_items_type": 1, "include_always": "False", "question_ID": 0, "questions": null}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 135, "checklist_items_checklistID": "14.2.1", "checklist_items_content": "Verify that all components are up to date, preferably using a dependency checker during build or compile time.", "checklist_items_type": 1, "include_always": "False", "question_ID": 1, "questions": "Does the sprint implement changes that affect and change CI/CD?"}, {"kb_item_id": "283", "kb_item_title": "insecure application defaults", "kb_items_content": "Description:\n\nWhen default sample applications, default users, etc\nare not removed from your production environment you\nare increasing an attackers potentiall attack surface significantly.\n\nSolution:\n\nVerify that all unneeded features, documentation, samples, \nconfigurations are removed, such as sample applications, \nplatform documentation, and default or example users.\n", "checklist_items_id": 136, "checklist_items_checklistID": "14.2.2", "checklist_items_content": "Verify that all unneeded features, documentation, samples, configurations are removed, such as sample applications, platform documentation, and default or example users.", "checklist_items_type": 1, "include_always": "False", "question_ID": 1, "questions": "Does the sprint implement changes that affect and change CI/CD?"}, {"kb_item_id": "223", "kb_item_title": "Application assets hosted on secure location", "kb_items_content": " Description:\n\nWhenever application assets such as JavaScript libraries or CSS styleshees are not hosted\non the application itself but on a external CDN which is not under your control these\nCDNs' can introduce security vulnerabilities. Whenever one of these CDN gets compromised\nattackers can include malicious scripts. Also whenever one of these CDNs' get out of service\nit could affect the operation of the application and even cause a denial of service.\n\n Solution:\n\nVerify that all application assets are hosted by the application, such as JavaScript libraries, CSS\nstylesheets and web fonts are hosted by the application rather than rely on a CDN or external\nprovider. \n", "checklist_items_id": 137, "checklist_items_checklistID": "14.2.3", "checklist_items_content": "Verify that if application assets, such as JavaScript libraries, CSS stylesheets or web fonts, are hosted externally on a content delivery network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset.", "checklist_items_type": 1, "include_always": "False", "question_ID": 1, "questions": "Does the sprint implement changes that affect and change CI/CD?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 138, "checklist_items_checklistID": "14.3.1", "checklist_items_content": "Verify that web or application server and framework error messages are configured to deliver user actionable, customized responses to eliminate any unintended security disclosures.", "checklist_items_type": 1, "include_always": "True", "question_ID": 28, "questions": "Is the application in need of a review of configurations and settings?"}, {"kb_item_id": "16", "kb_item_title": "Debug enabeling", "kb_items_content": " Description:\n\nSometimes it is possible through an \"enabling debug parameter\" to display technical\ninformation/secrets within the application. As a result, the attacker learns more about the\noperation of the application, increasing his attack surface. Sometimes having a debug flag \nenabled could even lead to code execution attacks (older versions of werkzeug) \n\n Solution:\n\nDisable the possibility to enable debug information on a live environment.\n", "checklist_items_id": 139, "checklist_items_checklistID": "14.3.2", "checklist_items_content": "Verify that web or application server and application framework debug modes are disabled in production to eliminate debug features, developer consoles, and unintended security disclosures.", "checklist_items_type": 1, "include_always": "True", "question_ID": 28, "questions": "Is the application in need of a review of configurations and settings?"}, {"kb_item_id": "130", "kb_item_title": "Verbose version information", "kb_items_content": " Description:\n\nRevealing system data or debugging information helps an adversary learn about the system\nand form a plan of attack. An information leak occurs when system data or debugging\ninformation leaves the program through an output stream or logging function.\n\n Solution:\n\nVerify that the HTTP headers do not expose detailed version information of system components. For each different type of server, there are hardening guides dedicated especially for this type of data leaking. The same applies for i.e any other leak of version information such as the version of your programming language or other services running to make your application function.\n", "checklist_items_id": 140, "checklist_items_checklistID": "14.3.3", "checklist_items_content": "Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components.", "checklist_items_type": 1, "include_always": "False", "question_ID": 28, "questions": "Is the application in need of a review of configurations and settings?"}, {"kb_item_id": "104", "kb_item_title": "Content type headers", "kb_items_content": " Description:\n\nSetting the right content headers is important for hardening your applications security,\nthis reduces exposure to driveby download attacks or sites serving user uploaded\ncontent that, by clever naming could be treated by MS Internet Explorer as executable or\ndynamic HTML files and thus can lead to security vulnerabilities.\n\n Solution:\n\nAn example of a content type header would be: \n\n ContentType: text/html; charset=UTF8\n or:\n ContentType: application/json;\n \n \nVerify that requests containing unexpected or missing content types are rejected with appropriate headers (HTTP response status 406 Unacceptable or 415 Unsupported Media Type).\n", "checklist_items_id": 141, "checklist_items_checklistID": "14.4.1", "checklist_items_content": "Verify that every HTTP response contains a content type header specifying a safe character set (e.g., UTF-8, ISO 8859-1).", "checklist_items_type": 1, "include_always": "False", "question_ID": 28, "questions": "Is the application in need of a review of configurations and settings?"}, {"kb_item_id": "193", "kb_item_title": "API resonses security headers", "kb_items_content": " Description:\n\nThere are some security headers which should be properly configured in order to protect some API callbacks against Reflective File Download and other type of injections.\n\nAlso check if the API response is dynamic, if user input is reflected in the response. If so, you must validate and encode the input, in order to prevent XSS and Same origin method execution attacks.\n\n Solution:\n\nSanitize your API's input (in this case they should just allow alphanumeric); escaping is not sufficient\n\nVerify that all API responses contain XContentTypeOptions: nosniff, to prevent the browser from interpreting files as something else than declared by the content type (this helps prevent XSS if the page is interpreted as html or js).\n\nAdd 'ContentDisposition: attachment; filename=\"filename.extension\"' with extension corresponding the file extension and contenttype, on APIs that are not going to be rendered\n\n", "checklist_items_id": 142, "checklist_items_checklistID": "14.4.2", "checklist_items_content": "Verify that all API responses contain Content-Disposition: attachment; filename=\"api.json\" (or other appropriate filename for the content type).", "checklist_items_type": 1, "include_always": "False", "question_ID": 28, "questions": "Is the application in need of a review of configurations and settings?"}, {"kb_item_id": "178", "kb_item_title": "Content security policy headers", "kb_items_content": " Description:\n\nThe main use of the content security policy header is to, detect, report, and reject XSS attacks. The core issue in relation to XSS attacks is the browser's inability to distinguish between a script that's intended to be part of your application, and a script that's been maliciously injected by a thirdparty.\nWith the use of CSP(Content Security policy), we can tell the browser which script is safe to execute and which scripts are most likely been injected by an attacker.\n\n Solution:\n\nA best practice for implementing CSP in your application would be to externalize all\nJavaScript within the web pages.\n\nSo this:\n\n \n\n\tfoobar!\n\nMust become this:\n\n\t\n\tLet's foobar!\n\nThe header for this code could look something like:\n\n ContentSecurityPolicy: defaultsrc'self'; objectsrc'none'; scriptsrc'https://mycdn.com'\n \nSince it is not entirely realistic to implement all JavaScript on external pages we can apply sort of a crosssite request forgery token to your inline JavaScript. This way the browser can again distinguish the difference between code which is part of the application against probable malicious injected code, in CSP this is called the 'nonce'. Of course, this method is also very applicable on your existing code and designs.\nNow, to use this nonce you have to supply your inline script tags with the nonce attribute. Firstly, it's important that the nonce changes for each response. Otherwise, the nonce would become guessable. So it should also contain a high entropy and should be hard to predict. Similar to the operation of the CSRF tokens, the nonce becomes impossible for the attacker to predict making it difficult to execute a successful XSS attack.\n\n\nInline JavaScript example containing nonce:\n\t\n\t\n \nMatching header example:\n\n ContentSecurityPolicy: scriptsrc 'noncesfsdf03nceI23wlsgle9h3sdd21'\n ```\nThere is a whole lot more to learn about the CSP header for indepth implementation in your application. This knowledge base item just scratches the surface and it would be highly recommended to gain more indepth knowledge about this powerful header\n\n Very Important:\nWhen applying the CSP header, although it blocks XSS attacks. Your\napplication still remains vulnerable to HTML and other code injections.\nSo this is not a substitute for, validation, sanitizing and encoding of userinput.\n", "checklist_items_id": 143, "checklist_items_checklistID": "14.4.3", "checklist_items_content": "Verify that a content security policy (CSPv2) is in place that helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection vulnerabilities.", "checklist_items_type": 1, "include_always": "False", "question_ID": 28, "questions": "Is the application in need of a review of configurations and settings?"}, {"kb_item_id": "193", "kb_item_title": "API resonses security headers", "kb_items_content": " Description:\n\nThere are some security headers which should be properly configured in order to protect some API callbacks against Reflective File Download and other type of injections.\n\nAlso check if the API response is dynamic, if user input is reflected in the response. If so, you must validate and encode the input, in order to prevent XSS and Same origin method execution attacks.\n\n Solution:\n\nSanitize your API's input (in this case they should just allow alphanumeric); escaping is not sufficient\n\nVerify that all API responses contain XContentTypeOptions: nosniff, to prevent the browser from interpreting files as something else than declared by the content type (this helps prevent XSS if the page is interpreted as html or js).\n\nAdd 'ContentDisposition: attachment; filename=\"filename.extension\"' with extension corresponding the file extension and contenttype, on APIs that are not going to be rendered\n\n", "checklist_items_id": 144, "checklist_items_checklistID": "14.4.4", "checklist_items_content": "Verify that all responses contain X-Content-Type-Options: nosniff.", "checklist_items_type": 1, "include_always": "False", "question_ID": 28, "questions": "Is the application in need of a review of configurations and settings?"}, {"kb_item_id": "192", "kb_item_title": "HTTP strict transport security", "kb_items_content": " Description:\n\nHTTP Strict Transport Security (HSTS) is an optin security enhancement that is specified\nby a web application through the use of a special response header. Once a supported browser\nreceives this header that browser will prevent any communications from being sent over\nHTTP to the specified domain and will instead send all communications over HTTPS. It also\nprevents HTTPS click through prompts on browsers. \n\nHSTS addresses the following threats:\n\n1. User bookmarks or manually types http://example.com and is subject to a maninthemiddle attacker\n HSTS automatically redirects HTTP requests to HTTPS for the target domain\n2. Web application that is intended to be purely HTTPS inadvertently contains HTTP links or serves content over HTTP\n HSTS automatically redirects HTTP requests to HTTPS for the target domain\n3. A maninthemiddle attacker attempts to intercept traffic from a victim user using an invalid certificate and \n hopes the user will accept the bad certificate\n4. HSTS does not allow a user to override the invalid certificate message\n\n Solution:\n\nWhen users are visiting the application it should set the following header:\nThese headers should be set in a base class which always sets the header no mather what\npage the users initially visit.\n\nSimple example, using a long (1 year) maxage:\n StrictTransportSecurity: maxage=31536000\n\nIf all present and future subdomains will be HTTPS:\n StrictTransportSecurity: maxage=31536000; includeSubDomains\n\n CAUTION: \nSite owners can use HSTS to identify users without cookies. This can lead to a significant\nprivacy leak.\n\nCookies can be manipulated from subdomains, so omitting the include \"includeSubDomains\"\noption permits a broad range of cookierelated attacks that HSTS would otherwise prevent\nby requiring a valid certificate for a subdomain. Ensuring the \"Secure Flag\" is set on all\ncookies will also prevent, some, but not all, of the same attacks.\n\n", "checklist_items_id": 145, "checklist_items_checklistID": "14.4.5", "checklist_items_content": "Verify that HTTP Strict Transport Security headers are included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=15724800; includeSubdomains.", "checklist_items_type": 1, "include_always": "False", "question_ID": 28, "questions": "Is the application in need of a review of configurations and settings?"}, {"kb_item_id": "282", "kb_item_title": "Referrer policy header", "kb_items_content": "Description:\nRequests made from a document, and for navigations away from that document\nare associated with a Referer header. While the header can be suppressed for\nlinks with the noreferrer link type, authors might wish to control the Referer\nheader more directly for a number of reasons,\n\n Privacy\nA social networking site has a profile page for each of its users, \nand users add hyperlinks from their profile page to their favorite bands. \nThe social networking site might not wish to leak the user\u2019s profile URL \nto the band web sites when other users follow those hyperlinks \n(because the profile URLs might reveal the identity of the owner of the profile).\n\nSome social networking sites, however, might wish to inform the band web sites that\nthe links originated from the social networking site but not reveal which specific\nuser\u2019s profile contained the links.\n\n Security\nA web application uses HTTPS and a URLbased session identifier. The web application might\nwish to link to HTTPS resources on other web sites without leaking the user\u2019s session \nidentifier in the URL.\n\nAlternatively, a web application may use URLs which themselves grant some capability. \nControlling the referrer can help prevent these capability URLs from leaking via \nreferrer headers.\n\nNote that there are other ways for capability URLs to leak, and controlling \nthe referrer is not enough to control all those potential leaks.\n\n Trackback\nA blog hosted over HTTPS might wish to link to a blog hosted over HTTP and \nreceive trackback links.\n\nSolution:\n\nFor more information about the policy and how it should be implemented please\nvisit the following link,\n\nhttps://www.w3.org/TR/referrerpolicy/referrerpolicies\n", "checklist_items_id": 146, "checklist_items_checklistID": "14.4.6", "checklist_items_content": "Verify that a suitable \"Referrer-Policy\" header is included, such as \"no-referrer\" or \"same-origin\".", "checklist_items_type": 1, "include_always": "False", "question_ID": 28, "questions": "Is the application in need of a review of configurations and settings?"}, {"kb_item_id": "20", "kb_item_title": "Include anti clickjacking headers", "kb_items_content": " Description:\n\nClickjacking, also known as a \"UI redress attack\", is when an attacker uses multiple\ntransparent or opaque layers to trick a user into clicking on a button or link on another\npage when they were intending to click on the top level page. Thus, the attacker is\n\"hijacking\" clicks meant for their page and routing them to another page, most likely\nowned by another application, domain, or both.\n\nUsing a similar technique, keystrokes can also be hijacked. With a carefully crafted\ncombination of stylesheets, iframes, and text boxes, a user can be led to believe they\nare typing in the password to their email or bank account, but are instead typing into an\ninvisible frame controlled by the attacker.\n\n Solution:\n\nTo avoid your application from being clickjacked you can add the XframeOptions header\nto your application. These headers can be configured as:\n\n XframeOptions: deny\n\nThe page cannot be displayed in a frame, regardless of the site attempting to do so.\n\n XFrameOptions: sameorign \n\nThe page can only be displayed in a frame on the same origin as the page itself.\n\n XFrameOptions: ALLOWFROM uri\n\nThe page can only be displayed in a frame on the specified origin.\n\nYou may also want to consider to include \"Framebreaking/Framebusting\" defense for legacy\nbrowsers that do not support XFrameOption headers.\n\nSource:\nhttps://www.codemagi.com/blog/post/194\n", "checklist_items_id": 147, "checklist_items_checklistID": "14.4.7", "checklist_items_content": "Verify that a suitable X-Frame-Options or Content-Security-Policy: frame-ancestors header is in use for sites where content should not be embedded in a third-party site.", "checklist_items_type": 1, "include_always": "False", "question_ID": 28, "questions": "Is the application in need of a review of configurations and settings?"}, {"kb_item_id": "129", "kb_item_title": "HTTP request methods", "kb_items_content": " Description:\n\nHTTP offers a number of methods that can be used to perform actions on the web server.\nMany of these methods are designed to aid developers in deploying and testing\nHTTP applications. These HTTP methods can be used for nefarious purposes if the web\nserver is misconfigured. It recommended to read about the different available methods, their purposes and\nlimitations.\n\nAvailable method are:\n\nGET\nThe GET method requests a representation of the specified resource. Requests using GET should only retrieve data and should have no other effect. (This is also true of some other HTTP methods.)[1] The W3C has published guidance principles on this distinction, saying, \"Web application design should be informed by the above principles, but also by the relevant limitations.\n\nHEAD\nThe HEAD method asks for a response identical to that of a GET request, but without the response body. This is useful for retrieving metainformation written in response headers, without having to transport the entire content.\n\nPOST\nThe POST method requests that the server accept the entity enclosed in the request as a new subordinate of the web resource identified by the URI. The data POSTed might be, for example, an annotation for existing resources; a message for a bulletin board, newsgroup, mailing list, or comment thread; a block of data that is the result of submitting a web form to a datahandling process; or an item to add to a database.\n\n\nPUT\nThe PUT method requests that the enclosed entity be stored under the supplied URI. If the URI refers to an already existing resource, it is modified; if the URI does not point to an existing resource, then the server can create the resource with that URI.\n\n\nDELETE\nThe DELETE method deletes the specified resource.\n\n\nTRACE\nThe TRACE method echoes the received request so that a client can see what (if any) changes or additions have been made by intermediate servers.\n\nOPTIONS\nThe OPTIONS method returns the HTTP methods that the server supports for the specified URL. This can be used to check the functionality of a web server by requesting '' instead of a specific resource.\n\nCONNECT\nThe CONNECT method converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSLencrypted communication (HTTPS) through an unencrypted HTTP proxy.\n\nPATCH\nThe PATCH method applies partial modifications to a resource.\n\nSome of the methods (for example, GET, HEAD, OPTIONS and TRACE) are, by convention, defined as safe, which means they are intended only for information retrieval and should not change the state of the server. In other words, they should not have side effects, beyond relatively harmless effects such as logging, web caching, the serving of banner advertisements or incrementing a web counter. Making arbitrary GET requests without regard to the context of the application's state should therefore be considered safe. However, this is not mandated by the standard, and it is explicitly acknowledged that it cannot be guaranteed.\n\nDespite the prescribed safety of GET requests, in practice their handling by the server is not technically limited in any way. Therefore, careless or deliberate programming can cause nontrivial changes on the server. This is discouraged, because it can cause problems for web caching, search engines and other automated agents, which can make unintended changes on the server. For example, a website might allow deletion of a resource through a URL such as http://example.com/article/1234/delete, which, if arbitrarily fetched, even using GET, would simply delete the article.\n\nBy contrast, methods such as POST, PUT, DELETE and PATCH are intended for actions that may cause side effects either on the server, or external side effects such as financial transactions or transmission of email. Such methods are therefore not usually used by conforming web robots or web crawlers; some that do not conform tend to make requests without regard to context or consequences.\n\nMethods PUT and DELETE are defined to be idempotent, meaning that multiple identical requests should have the same effect as a single request (note that idempotence refers to the state of the system after the request has completed, so while the action the server takes (e.g. deleting a record) or the response code it returns may be different on subsequent requests, the system state will be the same every time). Methods GET, HEAD, OPTIONS and TRACE, being prescribed as safe, should also be idempotent, as HTTP is a stateless protocol.\n\nIn contrast, the POST method is not necessarily idempotent, and therefore sending an identical POST request multiple times may further affect state or cause further side effects (such as financial transactions). In some cases this may be desirable, but in other cases this could be due to an accident, such as when a user does not realize that their action will result in sending another request, or they did not receive adequate feedback that their first request was successful. While web browsers may show alert dialog boxes to warn users in some cases where reloading a page may resubmit a POST request, it is generally up to the web application to handle cases where a POST request should not be submitted more than once.\n\nNote that whether a method is idempotent is not enforced by the protocol or web server. It is perfectly possible to write a web application in which (for example) a database insert or other nonidempotent action is triggered by a GET or other request. Ignoring this recommendation, however, may result in undesirable consequences, if a user agent assumes that repeating the same request is safe when it is not.\n\nThe TRACE method can be used as part of a class of attacks known as crosssite tracing; for that reason, common security advice is for it to be disabled in the server configuration. Microsoft IIS supports a proprietary \"TRACK\" method, which behaves similarly, and which is likewise recommended to be disabled\n\n Solution:\n\nVerify that the application accepts only a defined set of HTTP request methods, such as\nGET and POST and unused methods are explicitly blocked/disabled.\n", "checklist_items_id": 148, "checklist_items_checklistID": "14.5.1", "checklist_items_content": "Verify that the application server only accepts the HTTP methods in use by the application or API, including pre-flight OPTIONS.", "checklist_items_type": 1, "include_always": "False", "question_ID": 28, "questions": "Is the application in need of a review of configurations and settings?"}, {"kb_item_id": "999", "kb_item_title": "not available item", "kb_items_content": " Description:\n\nThis item is currently not available.\n\n\n\n Solution:\n\nThis item is currently not available.\n", "checklist_items_id": 149, "checklist_items_checklistID": "14.5.2", "checklist_items_content": "Verify that the supplied Origin header is not used for authentication or access control decisions, as the Origin header can easily be changed by an attacker.", "checklist_items_type": 1, "include_always": "False", "question_ID": 28, "questions": "Is the application in need of a review of configurations and settings?"}, {"kb_item_id": "112", "kb_item_title": "Cross origin resource sharing", "kb_items_content": " Description:\n\nCross Origin Resource Sharing or CORS is a mechanism that enables a web browser to perform\n'crossdomain' requests using the XMLHttpRequest L2 API in a controlled manner.\nIn the past, the XMLHttpRequest L1 API only allowed requests to be sent within the same\norigin as it was restricted by the same origin policy.\n\n Solution:\n\nCrossOrigin requests have an Origin header, that identifies the domain initiating the request and is always sent to the server. CORS defines the protocol to use a web browser and a server to determine whether a crossorigin request is allowed. In order to accomplish this goal, there are a few HTTP headers involved in this process, that are supported by all major browsers:\n\n Origin\n AccessControlRequestMethod\n AccessControlRequestHeaders\n AccessControlAllowOrigin\n AccessControlAllowCredentials\n AccessControlAllowMethods\n AccessControlAllowHeaders\n\nThings you must consider when using CORS\n\n1. Validate URLs passed to XMLHttpRequest.open. Current browsers allow these URLs to be\ncross domain; this behavior can lead to code injection by a remote attacker. Pay extra\nattention to absolute URLs.\n\n2. Ensure that URLs responding with AccessControlAllowOrigin: do not include any\nsensitive content or information that might aid an attacker in further attacks.\nUse the AccessControlAllowOrigin header only on chosen URLs that need to be\naccessed crossdomain. Don't use the header for the whole domain.\n\n3. Allow only selected, trusted domains in the AccessControlAllowOrigin header.\nPrefer whitelisting domains over blacklisting or allowing any domain\n(do not use * wildcard nor blindly return the Origin header content without any checks)\n\n4. Keep in mind that CORS does not prevent the requested data from going to an\nunauthenticated location. It's still important for the server to perform usual\nCSRF prevention.\n\n5. While the RFC recommends a preflight request with the OPTIONS verb, current\nimplementations might not perform this request, so it's important that \"ordinary\"\n(GET and POST) requests perform any access control necessary.\n\n6. Discard requests received over plain HTTP with HTTPS origins to prevent mixed\ncontent bugs.\n\n7. Don't rely only on the Origin header for Access Control checks. Browser always sends\nthis header in CORS requests, but may be spoofed outside the browser.\nApplicationlevel protocols should be used to protect sensitive data.\n\nNOTE: \nModern application frameworks do dynamically allocation of the origin header, resulting in the browser\nalso allowing to send the \"AccessControlAllowCredentials: true\" header as well in requests. \nWhenever JSON web tokens are being send in cookies rather than headers, potential attackers could abuse this behaviour to \nmake unauthenticated XHR get requests on the authenticated users behalf to read sensitive information from the \npages.\n", "checklist_items_id": 150, "checklist_items_checklistID": "14.5.3", "checklist_items_content": "Verify that the cross-domain resource sharing (CORS) Access-Control-Allow-Origin header uses a strict white-list of trusted domains to match against and does not support the \"null\" origin.", "checklist_items_type": 1, "include_always": "False", "question_ID": 28, "questions": "Is the application in need of a review of configurations and settings?"}]}