#java
Rulesets (30)
r2cScan code for potential security issues that require additional review. Recommended for teams looking to set up guardrails or to flag troublesome spots for further review.
Use Semgrep as a universal linter to identify vulnerabilities and code smells in your code base with the FindSecBugs (https://find-sec-bugs.github.io/) rule pack.
r2cScan code for potential security issues that require additional review. Recommended for teams looking to set up guardrails or to flag troublesome spots for further review.
r2cA collection of opinionated rules for best practices in popular languages. Recommended for users who want really strict coding standards.
r2cDefault ruleset for Java, curated by r2c.
r2cSecure defaults for XSS prevention
r2cr2c Java security rules, combined
r2cFind common bugs, errors, and logic issues in popular languages.
Colleen DaiEnsure your code communicates over encrypted channels instead of plaintext.
r2cSecure XSS defaults for HttpServlets+JSP.
r2cRule pack for detecting insecure transport in java spring.
r2cRules for detecting secrets checked into version control
r2cRule pack for detecting insecure transport in java stdlib.
r2cUse recommended rulesets specific to your project. Auto config is not a ruleset but a mode that scans for languages and frameworks and then uses the Semgrep Registry to select recommended rules. Semgrep will send a list of languages, frameworks, and your project URL to the Registry when using auto mode (but code is never uploaded).
Another test ruleset
r2cOmni pack for insecure transport rules
r2cRule pack for detecting insecure transport in java spring.
Leverage all Gitlab provided rules with the gitlab rulepack.
Colleen DaiEnsure your code communicates over encrypted channels instead of plaintext.
Vasilii ErmilovSecure defaults for Command injection prevention
r2cScan for runtime errors, logic bus, and high-confidence security vulnerabilities. Recommended for use in CI to block serious issues from reaching production. Supports Python, Java, JavaScript, and Go.
r2cScan for runtime errors, logic bus, and high-confidence security vulnerabilities. Recommended for use in CI to block serious issues from reaching production.
Colleen DaiSQL injection guardrails. Checks for non-constant SQL queries and other SQLi.
Mobile Security FrameworkWritten by the MobSF team. See https://github.com/MobSF/mobsfscan for more.
Colleen DaiOWASP Java Benchmark ruleset, a subset of java rules for faster results.
Rulset for reverse shells, by Kurt Boberg
r2cRule pack for detecting insecure transport in java spring.
Rules (417)
MobSFThe App logs information. Please ensure that sensitive information is never logged.
MobSFA hardcoded password in plain text is identified.
MobSFA hardcoded username in plain text is identified.
MobSFA hardcoded Key is identified.
MobSFA hardcoded secret is identified.
MobSFThe file is World Readable. Any App can read from the file.
MobSFThe file is World Readable and Writable. Any App can read/write to the file.
MobSFThis app does not uses SafetyNet Attestation API that provides cryptographically-signed attestation, assessing the device's integrity. This check helps to ensure that the servers are interacting with the genuine app running on a genuine Android device.
MobSFHardcoded encryption key makes AES symmetric encryption useless. An attacker can easily reverse engineer the application and recover the keys.
MobSFThe App uses the encryption mode CBC with PKCS5/PKCS7 padding. This configuration is vulnerable to padding oracle attacks.
MobSFThe IV for AES CBC mode should be random. A static IV makes the ciphertext vulnerable to Chosen Plaintext Attack.
MobSFThe App uses an insecure Random Number Generator.
MobSFSSLv3 is insecure and has multiple known vulnerabilities.
MobSFThis App uses RSA Crypto without OAEP padding. The purpose of the padding scheme is to prevent a number of attacks on RSA that only work when the encryption is performed without padding.
MobSFSHA1 Hash algorithm used. The SHA1 hash is known to have hash collisions.
MobSFWeak encryption algorithm identified. This algorithm is vulnerable to cryptographic attacks.
MobSFDefaultHTTPClient() with default constructor is not compatible with TLS 1.2.
MobSFWebView load files from external storage. Files in external storage can be modified by any application.
MobSFWebView File System Access is enabled. An attacker able to inject script into a WebView, could exploit the opportunity to access local resources.
MobSFInsecure WebView Implementation. WebView ignores SSL Certificate errors and accept any SSL Certificate. This application is vulnerable to MITM attacks.
MobSFEnsure that javascript interface is implemented securely. Execution of user controlled code in WebView is a critical Security issue.
MobSFXMLDecoder should not be used to parse untrusted data. Deserializing user input can lead to arbitrary code execution. Use an alternative and explicitly disable external entities.
MobSFXML external entities are enabled for this XMLInputFactory. This is vulnerable to XML external entity attacks. Disable external entities by setting "javax.xml.stream.isSupportingExternalEntities" to false.
MobSFXML external entities are not explicitly disabled for this XMLInputFactory. This could be vulnerable to XML external entity vulnerabilities. Explicitly disable external entities by setting "javax.xml.stream.isSupportingExternalEntities" to false.
MobSFHidden elements in view can be used to hide data from user. But this data can be leaked.
MobSFThis app does not have capabilities to prevent against Screenshots from Recent Task History/ Now On Tap etc.
MobSFThis app does not have root detection capabilities. Running a sensitive application on a rooted device questions the device integrity and affects users data.
MobSFThis app does not have capabilities to prevent tapjacking attacks. An attacker can hijack the user's taps and tricks him into performing some critical operations that he did not intend to.
MobSFThis app does not enforce TLS Certificate Transparency that helps to detect SSL certificates that have been mistakenly issued by a certificate authority or maliciously acquired from an otherwise unimpeachable certificate authority.
MobSFThis app does not use a TLS/SSL certificate or public key pinning in code to detect or prevent MITM attacks in secure communication channel. Please verify if pinning is enabled in `network_security_config.xml`.
MobSFThe App uses ECB mode in Cryptographic encryption algorithm. ECB mode is known to be weak as it results in the same ciphertext for identical blocks of plaintext.
MobSFCalling Cipher.getInstance("AES") will return AES ECB mode by default. ECB mode is known to be weak as it results in the same ciphertext for identical blocks of plaintext.
MobSFWeak Hash algorithm used. The hash algorithm is known to have hash collisions.
MobSFThe App may use weak IVs like "0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00" or "0x01,0x02,0x03,0x04,0x05,0x06,0x07". Not using a random IV makes the resulting ciphertext much more predictable and susceptible to a dictionary attack.
MobSFCryptographic implementations with insufficient key length is susceptible to bruteforce attacks.
MobSFThe app uses jackson deserialization library. Deserialization of untrusted input can result in arbitrary code execution. Consider using HMACs to sign the data stream to make sure it is not tampered with, or consider only transmitting object fields and populating a new object.
MobSFFound object deserialization using ObjectInputStream. Deserializing entire Java objects is dangerous because malicious actors can create Java object streams with unintended consequences. Ensure that the objects being deserialized are not user-controlled. Consider using HMACs to sign the data stream to make sure it is not tampered with, or consider only transmitting object fields and populating a new object.
MobSFUser controlled strings in exec() will result in command execution.
MobSFA formatted or concatenated string was detected as input to a java.lang.Runtime call. This is dangerous if a variable is controlled by user input and could result in a command injection. Ensure your variables are not controlled by users or sufficiently sanitized.
MobSFApp uses SQLite Database and execute raw SQL query. Untrusted user input in raw SQL queries can cause SQL Injection. Also sensitive information should be encrypted and written to the database.
MobSFInsecure Implementation of SSL. Trusting all the certificates or accepting self signed certificates is a critical Security Hole. This application is vulnerable to MITM attacks.
MobSFRemote WebView debugging is enabled. This allows an attacker with debugging access to interact with the webview and steal or corrupt data.
returntocorpA parameter being passed directly into HttpClient functions most likely lead to SSRF.
returntocorpA parameter being passed directly into CloseableHttpClient functions most likely lead to SSRF.
returntocorpNon-exhaustive list of Libraries that provide functionality to accept URL as a parameter
returntocorpStrings should not be compared with '=='. This is a reference comparison operator. Use '.equals()' instead.
returntocorpDetected SHA1 hash algorithm which is considered insecure. SHA1 is not collision resistant and is therefore not suitable as a cryptographic signature. Use SHA256 or SHA3 instead.
returntocorpDetected MD5 hash algorithm which is considered insecure. MD5 is not collision resistant and is therefore not suitable as a cryptographic signature. Use SHA256 or SHA3 instead.
returntocorpA parameter being passed directly into java.net.URL function most likely lead to SSRF.
returntocorpThe value of `$X` is being ignored and will be used in the conditional test
returntocorp`$X == $X` or `$X != $X` is always true. (Unless the value compared is a float or double). To test if `$X` is not-a-number, use `Double.isNaN($X)`.
returntocorpThis if statement will always have the same behavior and is therefore unnecessary.
Cryptographic keys should not be kept in the source code. The source code can be widely shared in an enterprise environment, and is certainly shared in open source. To be managed safely, passwords and secret keys should be stored in separate configuration files or keystores.
Cryptographic keys should not be kept in the source code. The source code can be widely shared in an enterprise environment, and is certainly shared in open source. To be managed safely, passwords and secret keys should be stored in separate configuration files or keystores.
Cryptographic keys should not be kept in the source code. The source code can be widely shared in an enterprise environment, and is certainly shared in open source. To be managed safely, passwords and secret keys should be stored in separate configuration files or keystores.
Cryptographic keys should not be kept in the source code. The source code can be widely shared in an enterprise environment, and is certainly shared in open source. To be managed safely, passwords and secret keys should be stored in separate configuration files or keystores.
returntocorpXMLInputFactory being instantiated without calling the setProperty functions that are generally used for disabling entity processing
returntocorpSAXParserFactory being instantiated without calling the setFeature functions that are generally used for disabling entity processing
returntocorpIt looks like MD5 is used as a password hash. MD5 is not considered a secure password hash because it can be cracked by an attacker in a short amount of time. Use a suitable password hashing function such as PBKDF2 or bcrypt. You can use `javax.crypto.SecretKeyFactory` with `SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1")` or, if using Spring, `org.springframework.security.crypto.bcrypt`.
returntocorpDetected input from a HTTPServletRequest going into a session command, like `setAttribute`. User input into such a command could lead to an attacker inputting malicious code into your session parameters, blurring the line between what's trusted and untrusted, and therefore leading to a trust boundary violation. This could lead to programmers trusting unvalidated data. Instead, thoroughly sanitize user input before passing it into such function calls.
returntocorpDetected input from a HTTPServletRequest going into a XPath evaluate or compile command. This could lead to xpath injection if variables passed into the evaluate or compile commands are not properly sanitized. Xpath injection could lead to unauthorized access to sensitive information in XML documents. Instead, thoroughly sanitize user input or use parameterized xpath queries if you can.
returntocorpCross-site scripting detected in HttpServletResponse writer with variable '$VAR'. User input was detected going directly from the HttpServletRequest into output. Ensure your data is properly encoded using org.owasp.encoder.Encode.forHtml: 'Encode.forHtml($VAR)'.
returntocorpA Spring expression is built with a dynamic value. The source of the value(s) should be verified to avoid that unfiltered values fall into this risky code evaluation.
returntocorpCSRF is disabled for this configuration. This is a security risk.
returntocorpDetected a potential path traversal. A malicious actor could control the location of this file, to include going backwards in the directory with '../'. To address this, ensure that user-controlled variables in file paths are sanitized. You may also consider using a utility method such as org.apache.commons.io.FilenameUtils.getName(...) to only retrieve the file name from the path.
returntocorpIn $METHOD, $X is used to construct a SQL query via string concatenation.
returntocorpWhen data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content.
returntocorpNullCipher was detected. This will not encrypt anything; the cipher text will be the same as the plain text. Use a valid, secure cipher: Cipher.getInstance("AES/CBC/PKCS7PADDING"). See https://owasp.org/www-community/Using_the_Java_Cryptographic_Extensions for more information.
returntocorpInitialization Vectors (IVs) for block ciphers should be randomly generated each time they are used. Using a static IV means the same plaintext encrypts to the same ciphertext every time, weakening the strength of the encryption.
returntocorpDetected the decoding of a JWT token without a verify step. JWT tokens must be verified before use, otherwise the token's integrity is unknown. This means a malicious actor could forge a JWT token with any claims. Call '.verify()' before using the token.
returntocorpA hard-coded credential was detected. It is not recommended to store credentials in source-code, as this risks secrets being leaked and used by either an internal or external malicious adversary. It is recommended to use environment variables to securely provide credentials or retrieve credentials from a secure vault or HSM (Hardware Security Module).
returntocorpDetected use of the 'none' algorithm in a JWT token. The 'none' algorithm assumes the integrity of the token has already been verified. This would allow a malicious actor to forge a JWT token that will automatically be verified. Do not explicitly use the 'none' algorithm. Instead, use an algorithm such as 'HS256'.
returntocorpDetected use of the 'none' algorithm in a JWT token. The 'none' algorithm assumes the integrity of the token has already been verified. This would allow a malicious actor to forge a JWT token that will automatically be verified. Do not explicitly use the 'none' algorithm. Instead, use an algorithm such as 'HS256'.
returntocorpDetected anonymous LDAP bind. This permits anonymous users to execute LDAP statements. Consider enforcing authentication for LDAP. See https://docs.oracle.com/javase/tutorial/jndi/ldap/auth_mechs.html for more information.
returntocorpUsing less than 128 bits for Blowfish is considered insecure. Use 128 bits or more, or switch to use AES instead.
returntocorpUsing CBC with PKCS5Padding is susceptible to padding oracle attacks. A malicious actor could discern the difference between plaintext with valid or invalid padding. Further, CBC mode does not include any integrity checks. Use 'AES/GCM/NoPadding' instead.
returntocorpA formatted or concatenated string was detected as input to a ProcessBuilder call. This is dangerous if a variable is controlled by user input and could result in a command injection. Ensure your variables are not controlled by users or sufficiently sanitized.
returntocorpDES is considered deprecated. AES is the recommended cipher. Upgrade to use AES. See https://www.nist.gov/news-events/news/2005/06/nist-withdraws-outdated-data-encryption-standard for more information.
returntocorpTriple DES (3DES or DESede) is considered deprecated. AES is the recommended cipher. Upgrade to use AES.
returntocorpCipher in ECB mode is detected. ECB mode produces the same output for the same input each time which allows an attacker to intercept and replay the data. Further, ECB mode does not provide any integrity checking. See https://find-sec-bugs.github.io/bugs.htm#CIPHER_INTEGRITY.
returntocorpGCM IV/nonce is reused: encryption can be totally useless
returntocorpUsing RSA without OAEP mode weakens the encryption.
returntocorpCryptographic algorithms are notoriously difficult to get right. By implementing a custom message digest, you risk introducing security issues into your program. Use one of the many sound message digests already available to you: MessageDigest sha256Digest = MessageDigest.getInstance("SHA256");
returntocorpDefaultHttpClient is deprecated. Further, it does not support connections using TLS1.2, which makes using DefaultHttpClient a security hazard. Use HttpClientBuilder instead.
returntocorpInsecure HostnameVerifier implementation detected. This will accept any SSL certificate with any hostname, which creates the possibility for man-in-the-middle attacks.
returntocorpDetected empty trust manager implementations. This is dangerous because it accepts any certificate, enabling man-in-the-middle attacks. Consider using a KeyStore and TrustManagerFactory instead. See https://stackoverflow.com/questions/2642777/trusting-all-certificates-using-httpclient-over-https for more information.
returntocorpRSA keys should be at least 2048 bits based on NIST recommendation.
returntocorpA expression is built with a dynamic value. The source of the value(s) should be verified to avoid that unfiltered values fall into this risky code evaluation.
returntocorpAn expression is built with a dynamic value. The source of the value(s) should be verified to avoid that unfiltered values fall into this risky code evaluation.
returntocorpDetected a formatted string in a SQL statement. This could lead to SQL injection if variables in the SQL statement are not properly sanitized. Use a prepared statements (java.sql.PreparedStatement) instead. You can obtain a PreparedStatement using 'connection.prepareStatement'.
returntocorpOlder Java application servers are vulnerable to HTTP response splitting, which may occur if an HTTP request can be injected with CRLF characters. This finding is reported for completeness; it is recommended to ensure your environment is not affected by testing this yourself.
returntocorpInsecure SMTP connection detected. This connection will trust any SSL certificate. Enable certificate verification by setting 'email.setSSLCheckServerIdentity(true)'.
returntocorpSemgrep found potential reverse shell behavior
returntocorpPossible JDBC injection detected. Use the parameterized query feature available in queryForObject instead of concatenating or formatting strings: 'jdbc.queryForObject("select * from table where name = ?", Integer.class, parameterName);'
returntocorpAn object-returning LDAP search will allow attackers to control the LDAP response. This could lead to Remote Code Execution.
returntocorpDetected non-constant data passed into an LDAP query. If this data can be controlled by an external user, this is an LDAP injection. Ensure data passed to an LDAP query is not controllable; or properly sanitize the data.
returntocorpFound object deserialization using ObjectInputStream. Deserializing entire Java objects is dangerous because malicious actors can create Java object streams with unintended consequences. Ensure that the objects being deserialized are not user-controlled. If this must be done, consider using HMACs to sign the data stream to make sure it is not tampered with, or consider only transmitting object fields and populating a new object.
returntocorpA expression is built with a dynamic value. The source of the value(s) should be verified to avoid that unfiltered values fall into this risky code evaluation.
returntocorpDetected a formatted string in a SQL statement. This could lead to SQL injection if variables in the SQL statement are not properly sanitized. Use a prepared statements (java.sql.PreparedStatement) instead. You can obtain a PreparedStatement using 'connection.prepareStatement'.
returntocorpDetected potential code injection using ScriptEngine. Ensure user-controlled data cannot enter '.eval()', otherwise, this is a code injection vulnerability.
returntocorpDetected a formatted string in a SQL statement. This could lead to SQL injection if variables in the SQL statement are not properly sanitized. Use a prepared statements (java.sql.PreparedStatement) instead. You can obtain a PreparedStatement using 'connection.prepareStatement'.
returntocorpDetected a formatted string in a SQL statement. This could lead to SQL injection if variables in the SQL statement are not properly sanitized. Use a prepared statements (java.sql.PreparedStatement) instead. You can obtain a PreparedStatement using 'connection.prepareStatement'.
returntocorpDetected a formatted string in a SQL statement. This could lead to SQL injection if variables in the SQL statement are not properly sanitized. Use a prepared statements (java.sql.PreparedStatement) instead. You can obtain a PreparedStatement using 'connection.prepareStatement'.
returntocorpDetected a formatted string in a SQL statement. This could lead to SQL injection if variables in the SQL statement are not properly sanitized. Use a prepared statements (java.sql.PreparedStatement) instead. You can obtain a PreparedStatement using 'connection.prepareStatement'.
returntocorpDetected a formatted string in a SQL statement. This could lead to SQL injection if variables in the SQL statement are not properly sanitized. Use a prepared statements (java.sql.PreparedStatement) instead. You can obtain a PreparedStatement using 'connection.prepareStatement'.
returntocorpIf an attacker can supply values that the application then uses to determine which class to instantiate or which method to invoke, the potential exists for the attacker to create control flow paths through the application that were not intended by the application developers. This attack vector may allow the attacker to bypass authentication or access control checks or otherwise cause the application to behave in an unexpected manner.
returntocorpApplication redirects to a destination URL specified by a user-supplied parameter that is not validated. This could direct users to malicious locations. Consider using an allowlist to validate URLs.
returntocorpURL rewriting has significant security risks. Since session ID appears in the URL, it may be easily seen by third parties.
returntocorpAn insecure SSL context was detected. TLS versions 1.0, 1.1, and all SSL versions are considered weak encryption and are deprecated. Use SSLContext.getInstance("TLSv1.2") for the best security.
returntocorpDetected a request with potential user-input going into a OutputStream or Writer object. This bypasses any view or template environments, including HTML escaping, which may expose this application to cross-site scripting (XSS) vulnerabilities. Consider using a view technology such as JavaServer Faces (JSFs) which automatically escapes HTML views.
returntocorpIt looks like you're using an implementation of XSSRequestWrapper from dzone. (https://www.javacodegeeks.com/2012/07/anti-cross-site-scripting-xss-filter.html) The XSS filtering in this code is not secure and can be bypassed by malicious actors. It is recommended to use a stack that automatically escapes in your view or templates instead of filtering yourself.
returntocorpMarking code as privileged enables a piece of trusted code to temporarily enable access to more resources than are available directly to the code that called it. Be very careful in your use of the privileged construct, and always remember to make the privileged code section as small as possible.
returntocorpDetected a potential path traversal. A malicious actor could control the location of this file, to include going backwards in the directory with '../'. To address this, ensure that user-controlled variables in file paths are sanitized. You may also consider using a utility method such as org.apache.commons.io.FilenameUtils.getName(...) to only retrieve the file name from the path.
returntocorpJMS Object messages depend on Java Serialization for marshalling/unmarshalling of the message payload when ObjectMessage.getObject() is called. Deserialization of untrusted data can lead to security flaws; a remote attacker could via a crafted JMS ObjectMessage to execute arbitrary code with the permissions of the application listening/consuming JMS Messages. In this case, the JMS MessageListener consume an ObjectMessage type received inside the onMessage method, which may lead to arbitrary code execution when calling the $Y.getObject method.
returntocorpUsing a non-primitive class with Java RMI may be an insecure deserialization vulnerability. Depending on the underlying implementation. This object could be manipulated by a malicious actor allowing them to execute code on your system. Instead, use an integer ID to look up your object, or consider alternative serialization schemes such as JSON.
returntocorpUsing an arbitrary object ('Object $PARAM') with Java RMI is an insecure deserialization vulnerability. This object can be manipulated by a malicious actor allowing them to execute code on your system. Instead, use an integer ID to look up your object, or consider alternative serialization schemes such as JSON.
returntocorpDefault session middleware settings: `setSecure` not set to true. This ensures that the cookie is sent only over HTTPS to prevent cross-site scripting attacks.
returntocorpDetected a string argument from a public method contract in a raw SQL statement. This could lead to SQL injection if variables in the SQL statement are not properly sanitized. Use a prepared statements (java.sql.PreparedStatement) instead. You can obtain a PreparedStatement using 'connection.prepareStatement'.
returntocorpApplication redirects a user to a destination URL specified by a user supplied parameter that is not validated.
returntocorpDetected a method annotated with 'RequestMapping' that does not specify the HTTP method. CSRF protections are not enabled for GET, HEAD, TRACE, or OPTIONS, and by default all HTTP methods are allowed when the HTTP method is not explicitly specified. This means that a method that performs state changes could be vulnerable to CSRF attacks. To mitigate, add the 'method' field and specify the HTTP method (such as 'RequestMethod.POST').
returntocorpThis code contains bidirectional (bidi) characters. While this is useful for support of right-to-left languages such as Arabic or Hebrew, it can also be used to trick language parsers into executing code in a manner that is different from how it is displayed in code editing and review tools. If this is not what you were expecting, please review this code in an editor that can reveal hidden Unicode characters.
returntocorpPossible Lookup injection into Log4j messages. Lookups provide a way to add values to the Log4j messages at arbitrary places. If the message parameter contains an attacker controlled string, the attacker could inject arbitrary lookups, for instance '${java:runtime}'. This could lead to information disclosure or even remote code execution if 'log4j2.formatMsgNoLookups' is enabled. This was enabled by default until version 2.15.0.
returntocorpWhen a Restful webservice endpoint is configured to use wildcard mediaType {*/*} as a value for the @Consumes annotation, an attacker could abuse the SerializableProvider by sending a HTTP Request with a Content-Type of application/x-java-serialized-object. The body of that request would be processed by the SerializationProvider and could contain a malicious payload, which may lead to arbitrary code execution when calling the $Y.getObject method.
returntocorpSeam Logging API support an expression language to introduce bean property to log messages. The expression language can also be the source to unwanted code execution. In this context, an expression is built with a dynamic value. The source of the value(s) should be verified to avoid that unfiltered values fall into this risky code evaluation.
returntocorpWhen a Restful webservice endpoint isn't configured with a @Consumes annotation, an attacker could abuse the SerializableProvider by sending a HTTP Request with a Content-Type of application/x-java-serialized-object. The body of that request would be processed by the SerializationProvider and could contain a malicious payload, which may lead to arbitrary code execution. Instead, add a @Consumes annotation to the function or class.
returntocorpDetected use of a Java socket that is not encrypted. As a result, the traffic could be read by an attacker intercepting the network traffic. Use an SSLSocket created by 'SSLSocketFactory' or 'SSLServerSocketFactory' instead.
returntocorpDetected file permissions that are overly permissive (read, write, and execute). It is generally a bad practices to set overly permissive file permission such as read+write+exec for all users. If the file affected is a configuration, a binary, a script or sensitive data, it can lead to privilege escalation or information leakage. Instead, follow the principle of least privilege and give users only the permissions they need.
returntocorpDetected input from a HTTPServletRequest going into a 'ProcessBuilder' or 'exec' command. This could lead to command injection if variables passed into the exec commands are not properly sanitized. Instead, avoid using these OS commands with user-supplied input, or, if you must use these commands, use a whitelist of specific values.
returntocorpDetected SHA1 hash algorithm which is considered insecure. SHA1 is not collision resistant and is therefore not suitable as a cryptographic signature. Instead, use PBKDF2 for password hashing or SHA256 or SHA512 for other hash function applications.
returntocorpDetected use of the functions `Math.random()` or `java.util.Random()`. These are both not cryptographically strong random number generators (RNGs). If you are using these RNGs to create passwords or secret tokens, use `java.security.SecureRandom` instead.
returntocorpDetected input from a HTTPServletRequest going into a SQL sink or statement. This could lead to SQL injection if variables in the SQL statement are not properly sanitized. Use parameterized SQL queries or properly sanitize user input instead.
returntocorpDetected input from a HTTPServletRequest going into an LDAP query. This could lead to LDAP injection if the input is not properly sanitized, which could result in attackers modifying objects in the LDAP tree structure. Ensure data passed to an LDAP query is not controllable or properly sanitize the data.
returntocorpUsed SnakeYAML org.yaml.snakeyaml.Yaml() constructor with no arguments, which is vulnerable to deserialization attacks. Use the one-argument Yaml(...) constructor instead, with SafeConstructor or a custom Constructor as the argument.
returntocorpDetected MD5 hash algorithm which is considered insecure. MD5 is not collision resistant and is therefore not suitable as a cryptographic signature. Use HMAC instead.
returntocorpDetected MD5 hash algorithm which is considered insecure. MD5 is not collision resistant and is therefore not suitable as a cryptographic signature. Use HMAC instead.
returntocorpA cookie was detected without setting the 'secure' flag. The 'secure' flag for cookies prevents the client from transmitting the cookie over insecure channels such as HTTP. Set the 'secure' flag by calling '$COOKIE.setSecure(true);'
returntocorpA formatted or concatenated string was detected as input to a java.lang.Runtime call. This is dangerous if a variable is controlled by user input and could result in a command injection. Ensure your variables are not controlled by users or sufficiently sanitized.
returntocorpA cookie was detected without setting the 'HttpOnly' flag. The 'HttpOnly' flag for cookies instructs the browser to forbid client-side scripts from reading the cookie. Set the 'HttpOnly' flag by calling 'cookie.setHttpOnly(true);'
returntocorpDetected cookie without the SameSite attribute.
returntocorpDetected non-constant data passed into a NoSQL query using the 'where' evaluation operator. If this data can be controlled by an external user, this is a NoSQL injection. Ensure data passed to the NoSQL query is not user controllable, or properly sanitize the data. Ideally, avoid using the 'where' operator at all and instead use the helper methods provided by com.mongodb.client.model.Filters with comparative operators such as eq, ne, lt, gt, etc.
returntocorpGCM detected, please check that IV/nonce is not reused, an Initialization Vector (IV) is a nonce used to randomize the encryption, so that even if multiple messages with identical plaintext are encrypted, the generated corresponding ciphertexts are different. Unlike the Key, the IV usually does not need to be secret, rather it is important that it is random and unique. Certain encryption schemes the IV is exchanged in public as part of the ciphertext. Reusing same Initialization Vector with the same Key to encrypt multiple plaintext blocks allows an attacker to compare the ciphertexts and then, with some assumptions on the content of the messages, to gain important information about the data being encrypted.
returntocorpDigester being instantiated without calling the setFeature functions that are generally used for disabling entity processing
returntocorpDocumentBuilderFactory being instantiated without calling the setFeature functions that are generally used for disabling entity processing
returntocorpSAXBuilder being instantiated without calling the setFeature functions that are generally used for disabling entity processing
returntocorpSAXReader being instantiated without calling the setFeature functions that are generally used for disabling entity processing
returntocorpXMLReader being instantiated without calling the setFeature functions that are generally used for disabling entity processing
returntocorpNon-exhaustive list of Libraries that provide functionality to accept XML as an input
returntocorp'Integer.toHexString()' strips leading zeroes from each byte if read byte-by-byte. This mistake weakens the hash value computed since it introduces more collisions. Use 'String.format("%02X", ...)' instead.
returntocorpChecks for redefinitions of functions that check TLS/SSL certificate verification. This can lead to vulnerabilities, as simple errors in the code can result in lack of proper certificate validation. This should only be used for debugging purposes because it leads to vulnerability to MTM attacks.
returntocorpChecks for outgoing connections to ftp servers via Spring plugin ftpSessionFactory. FTP does not encrypt traffic, possibly leading to PII being sent plaintext over the network.
returntocorpChecks for requests sent via Java Spring RestTemplate API to http:// URLS. This is dangerous because the server is attempting to connect to a website that does not encrypt traffic with TLS. Instead, send requests only to https:// URLS.
returntocorpChecks for redefinitions of the checkServerTrusted function in the X509TrustManager class that disables TLS/SSL certificate verification. This should only be used for debugging purposes because it leads to vulnerability to MTM attacks.
returntocorpDetects direct creations of SSLConnectionSocketFactories that don't disallow SSL v2, SSL v3, and TLS v1. SSLSocketFactory can be used to validate the identity of the HTTPS server against a list of trusted certificates. These protocols are deprecated due to POODLE, man in the middle attacks, and other vulnerabilities.
returntocorpDetects setting client protocols to insecure versions of TLS and SSL. These protocols are deprecated due to POODLE, man in the middle attacks, and other vulnerabilities.
returntocorpChecks for outgoing connections to ftp servers. FTP does not encrypt traffic, possibly leading to PII being sent plaintext over the network.
returntocorpChecks for requests sent via Apache HTTP Components to http:// URLS. This is dangerous because the server is attempting to connect to a website that does not encrypt traffic with TLS. Instead, send requests only to https:// URLS.
returntocorpChecks for requests sent via HttpClient to http:// URLS. This is dangerous because the server is attempting to connect to a website that does not encrypt traffic with TLS. Instead, send requests only to https:// URLS.
returntocorpChecks for requests sent via HttpURLConnection and URLObj to http:// URLS. This is dangerous because the server is attempting to connect to a website that does not encrypt traffic with TLS. Instead, send requests only to https:// URLS.
returntocorpInsecure transport rules to catch socket connections to http, telnet, and ftp servers. This is dangerous because these are protocols that do not encrypt traffic.
returntocorpChecks for attempts to connect through telnet. This is insecure as the telnet protocol supports no encryption, and data passes through unencrypted.
returntocorpChecks for cases where java applications are allowing unsafe renegotiation. This leaves the application vulnerable to a man-in-the-middle attack where chosen plain text is injected as prefix to a TLS connection.
returntocorpChecks for requests sent via Unirest to http:// URLS. This is dangerous because the server is attempting to connect to a website that does not encrypt traffic with TLS. Instead, send requests only to https:// URLS.
MobSFHidden elements in view can be used to hide data from user. But this data can be leaked.
MobSFThe App logs information. Please ensure that sensitive information is never logged.
MobSFA hardcoded password in plain text is identified.
MobSFA hardcoded username in plain text is identified.
MobSFA hardcoded Key is identified.
MobSFA hardcoded secret is identified.
MobSFThe file is World Readable. Any App can read from the file.
MobSFThe file is World Readable and Writable. Any App can read/write to the file.
MobSFThis app does not uses SafetyNet Attestation API that provides cryptographically-signed attestation, assessing the device's integrity. This check helps to ensure that the servers are interacting with the genuine app running on a genuine Android device.
MobSFThis app does not have capabilities to prevent against Screenshots from Recent Task History/ Now On Tap etc.
MobSFThis app does not have root detection capabilities. Running a sensitive application on a rooted device questions the device integrity and affects users data.
MobSFThis app does not have capabilities to prevent tapjacking attacks. An attacker can hijack the user's taps and tricks him into performing some critical operations that he did not intend to.
MobSFThis app does not enforce TLS Certificate Transparency that helps to detect SSL certificates that have been mistakenly issued by a certificate authority or maliciously acquired from an otherwise unimpeachable certificate authority.
MobSFThis app does not use a TLS/SSL certificate or public key pinning in code to detect or prevent MITM attacks in secure communication channel. Please verify if pinning is enabled in `network_security_config.xml`.
MobSFThe App uses ECB mode in Cryptographic encryption algorithm. ECB mode is known to be weak as it results in the same ciphertext for identical blocks of plaintext.
MobSFCalling Cipher.getInstance("AES") will return AES ECB mode by default. ECB mode is known to be weak as it results in the same ciphertext for identical blocks of plaintext.
MobSFHardcoded encryption key makes AES symmetric encryption useless. An attacker can easily reverse engineer the application and recover the keys.
MobSFThe App uses the encryption mode CBC with PKCS5/PKCS7 padding. This configuration is vulnerable to padding oracle attacks.
MobSFThe IV for AES CBC mode should be random. A static IV makes the ciphertext vulnerable to Chosen Plaintext Attack.
MobSFThe App uses an insecure Random Number Generator.
MobSFSSLv3 is insecure and has multiple known vulnerabilities.
MobSFThis App uses RSA Crypto without OAEP padding. The purpose of the padding scheme is to prevent a number of attacks on RSA that only work when the encryption is performed without padding.
MobSFSHA1 Hash algorithm used. The SHA1 hash is known to have hash collisions.
MobSFWeak encryption algorithm identified. This algorithm is vulnerable to cryptographic attacks.
MobSFWeak Hash algorithm used. The hash algorithm is known to have hash collisions.
MobSFThe App may use weak IVs like "0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00" or "0x01,0x02,0x03,0x04,0x05,0x06,0x07". Not using a random IV makes the resulting ciphertext much more predictable and susceptible to a dictionary attack.
MobSFCryptographic implementations with insufficient key length is susceptible to bruteforce attacks.
MobSFThe app uses jackson deserialization library. Deserialization of untrusted input can result in arbitrary code execution. Consider using HMACs to sign the data stream to make sure it is not tampered with, or consider only transmitting object fields and populating a new object.
MobSFFound object deserialization using ObjectInputStream. Deserializing entire Java objects is dangerous because malicious actors can create Java object streams with unintended consequences. Ensure that the objects being deserialized are not user-controlled. Consider using HMACs to sign the data stream to make sure it is not tampered with, or consider only transmitting object fields and populating a new object.
MobSFUser controlled strings in exec() will result in command execution.
MobSFA formatted or concatenated string was detected as input to a java.lang.Runtime call. This is dangerous if a variable is controlled by user input and could result in a command injection. Ensure your variables are not controlled by users or sufficiently sanitized.
MobSFApp uses SQLite Database and execute raw SQL query. Untrusted user input in raw SQL queries can cause SQL Injection. Also sensitive information should be encrypted and written to the database.
MobSFInsecure Implementation of SSL. Trusting all the certificates or accepting self signed certificates is a critical Security Hole. This application is vulnerable to MITM attacks.
MobSFDefaultHTTPClient() with default constructor is not compatible with TLS 1.2.
MobSFRemote WebView debugging is enabled. This allows an attacker with debugging access to interact with the webview and steal or corrupt data.
MobSFWebView load files from external storage. Files in external storage can be modified by any application.
MobSFWebView File System Access is enabled. An attacker able to inject script into a WebView, could exploit the opportunity to access local resources.
MobSFInsecure WebView Implementation. WebView ignores SSL Certificate errors and accept any SSL Certificate. This application is vulnerable to MITM attacks.
MobSFEnsure that javascript interface is implemented securely. Execution of user controlled code in WebView is a critical Security issue.
MobSFXMLDecoder should not be used to parse untrusted data. Deserializing user input can lead to arbitrary code execution. Use an alternative and explicitly disable external entities.
MobSFXML external entities are enabled for this XMLInputFactory. This is vulnerable to XML external entity attacks. Disable external entities by setting "javax.xml.stream.isSupportingExternalEntities" to false.
MobSFXML external entities are not explicitly disabled for this XMLInputFactory. This could be vulnerable to XML external entity vulnerabilities. Explicitly disable external entities by setting "javax.xml.stream.isSupportingExternalEntities" to false.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team Tier to see this rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
A new cookie is created without the HttpOnly flag set. The HttpOnly flag is a directive to the browser to make sure that the cookie can not be red by malicious script. When a user is the target of a "Cross-Site Scripting", the attacker would benefit greatly from getting the session id for example.
"Storing sensitive data in a persistent cookie for an extended period can lead to a breach of confidentiality or account compromise."
A new cookie is created without the Secure flag set. The Secure flag is a directive to the browser to make sure that the cookie is not sent for insecure communication (http://)
The information stored in a custom cookie should not be sensitive or related to the session. In most cases, sensitive data should only be stored in session and referenced by the user's session cookie.
When an HTTP request contains unexpected CR and LF characters, the server may respond with an output stream that is interpreted as two different HTTP responses (instead of one). An attacker can control the second response and mount attacks such as cross-site scripting and cache poisoning attacks.
This code constructs an HTTP Cookie using an untrusted HTTP parameter. If this cookie is added to an HTTP response, it will allow a HTTP response splitting vulnerability. See http://en.wikipedia.org/wiki/HTTP_response_splitting for more information.
Triple DES (also known as 3DES or DESede) is considered strong ciphers for modern applications. NIST recommends the usage of AES block ciphers instead of 3DES.
This code directly writes an HTTP parameter to an HTTP header, which allows for a HTTP response splitting vulnerability. See http://en.wikipedia.org/wiki/HTTP_response_splitting for more information.
A trust boundary can be thought of as line drawn through a program. On one side of the line, data is untrusted. On the other side of the line, data is assumed to be trustworthy. The purpose of validation logic is to allow data to safely cross the trust boundary - to move from untrusted to trusted. A trust boundary violation occurs when a program blurs the line between what is trusted and what is untrusted. By combining trusted and untrusted data in the same data structure, it becomes easier for programmers to mistakenly trust unvalidated data.
Prior to HTML5, Web browsers enforced the Same Origin Policy which ensures that in order for JavaScript to access the contents of a Web page, both the JavaScript and the Web page must originate from the same domain. Without the Same Origin Policy, a malicious website could serve up JavaScript that loads sensitive information from other websites using a client's credentials, cull through it, and communicate it back to the attacker. HTML5 makes it possible for JavaScript to access data across domains if a new HTTP header called Access-Control-Allow-Origin is defined. With this header, a Web server defines which other domains are allowed to access its domain using cross-origin requests. However, caution should be taken when defining the header because an overly permissive CORS policy will allow a malicious application to communicate with the victim application in an inappropriate way, leading to spoofing, data theft, relay and other attacks.
Prior to HTML5, Web browsers enforced the Same Origin Policy which ensures that in order for JavaScript to access the contents of a Web page, both the JavaScript and the Web page must originate from the same domain. Without the Same Origin Policy, a malicious website could serve up JavaScript that loads sensitive information from other websites using a client's credentials, cull through it, and communicate it back to the attacker. HTML5 makes it possible for JavaScript to access data across domains if a new HTTP header called Access-Control-Allow-Origin is defined. With this header, a Web server defines which other domains are allowed to access its domain using cross-origin requests. However, caution should be taken when defining the header because an overly permissive CORS policy will allow a malicious application to communicate with the victim application in an inappropriate way, leading to spoofing, data theft, relay and other attacks.
A small key size makes the ciphertext vulnerable to brute force attacks. At least 128 bits of entropy should be used when generating the key if use of Blowfish is required.
DES is considered strong ciphers for modern applications. Currently, NIST recommends the usage of AES block ciphers instead of DES.
An authentication cipher mode which provides better confidentiality of the encrypted data should be used instead of Electronic Code Book (ECB) mode, which does not provide good confidentiality. Specifically, ECB mode produces the same output for the same input each time. This allows an attacker to intercept and replay the data.
The ciphertext produced is susceptible to alteration by an adversary. This mean that the cipher provides no way to detect that the data has been tampered with. If the ciphertext can be controlled by an attacker, it could be altered without detection.
This specific mode of CBC with PKCS5Padding is susceptible to padding oracle attacks. An adversary could potentially decrypt the message if the system exposed the difference between plaintext with invalid padding or valid padding. The distinction between valid and invalid padding is usually revealed through distinct error messages being returned for each condition.
Implementing a custom MessageDigest is error-prone. National Institute of Standards and Technology(NIST) recommends the use of SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, or SHA-512/256.
DefaultHttpClient with default constructor is not compatible with TLS 1.2
The network communications for Hazelcast is configured to use a symmetric cipher (probably DES or Blowfish). Those ciphers alone do not provide integrity or secure authentication. The use of asymmetric encryption is preferred.
Detected an insufficient key size for DSA. NIST recommends a key size of 2048 or higher.
The NullCipher implements the Cipher interface by returning ciphertext identical to the supplied plaintext. In a few contexts, such as testing, a NullCipher may be appropriate. Avoid using the NullCipher. Its accidental use can introduce a significant confidentiality risk.
The software uses the RSA algorithm but does not incorporate Optimal Asymmetric Encryption Padding (OAEP), which might weaken the encryption.
DES is considered strong ciphers for modern applications. Currently, NIST recommends the usage of AES block ciphers instead of DES.
A HostnameVerifier that accept any host are often use because of certificate reuse on many hosts. As a consequence, this is vulnerable to Man-in-the-middleattacks attacks since the client will trust any certificate.
The Servlet can read GET and POST parameters from various methods. The value obtained should be considered unsafe."
This method is part of a REST Web Service (JSR311). The security of this web service should be analyzed; Authentication, if enforced, should be tested. Access control, if enforced, should be tested. The inputs should be tracked for potential vulnerabilities. The communication should ideally be over SSL.
This method is part of a SOAP Web Service (JSR224). The security of this web service should be analyzed; Authentication, if enforced, should be tested. Access control, if enforced, should be tested. The inputs should be tracked for potential vulnerabilities. The communication should ideally be over SSL.
Beyond using an SSL socket, you need to make sure your use of SSLSocketFactory does all the appropriate certificate validation checks to make sure you are not subject to man-in-the-middle attacks. Please read the OWASP Transport Layer Protection Cheat Sheet for details on how to do this correctly.
Unvalidated redirects occur when an application redirects a user to a destination URL specified by a user supplied parameter that is not validated. Such vulnerabilities can be used to facilitate phishing attacks.
A HostnameVerifier that accept any host are often use because of certificate reuse on many hosts. As a consequence, this is vulnerable to Man-in-the-middle attacks since the client will trust any certificate.
The filename provided by the FileUpload API can be tampered with by the client to reference unauthorized files. The provided filename should be properly validated to ensure it's properly structured, contains no unauthorized path characters (e.g., / \), and refers to an authorized file.
A file is opened to read its content. The filename comes from an input parameter. If an unfiltered parameter is passed to this file API, files from an arbitrary filesystem location could be read.
Form inputs should have minimal input validation. Preventive validation helps provide defense in depth against a variety of risks.
Constructing SimpleDB queries containing user input can allow an attacker to view unauthorized records.
An attacker can set arbitrary bean properties that can compromise system integrity. An attacker can leverage this functionality to access special bean properties like class.classLoader that will allow them to override system properties and potentially execute arbitrary code.
When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).
The highlighted API is used to execute a system command. If unfiltered input is passed to this API, it can lead to arbitrary command execution.
The method identified is susceptible to injection. The input should be validated and properly escaped.
The method identified is susceptible to injection. The input should be validated and properly escaped.
An expression is built with a dynamic value. The source of the value(s) should be verified to avoid that unfiltered values fall into this risky code evaluation.
Constructing a server-side redirect path with user input could allow an attacker to download application binaries (including application classes or jar files) or view arbitrary files within protected directories.
Concatenating unvalidated user input into a URL can allow an attacker to override the value of a request parameter. Attacker may be able to override existing parameter values, inject a new parameter or exploit variables out of a direct reach. HTTP Parameter Pollution (HPP) attacks consist of injecting encoded query string delimiters into other existing parameters. If a web application does not properly sanitize the user input, a malicious user may compromise the logic of the application to perform either client-side or server-side attacks.
Just like SQL, all inputs passed to an LDAP query need to be passed in safely. Unfortunately, LDAP doesn't have prepared statement interfaces like SQL. Therefore, the primary defense against LDAP injection is strong input validation of any untrusted data before including it in an LDAP query.
Overly permissive file permission
"A expression is built with a dynamic value. The source of the value(s) should be verified to avoid that unfiltered values fall into this risky code evaluation."
A file is opened to read its content. The filename comes from an input parameter. If an unfiltered parameter is passed to this file API, files from an arbitrary filesystem location could be read. This rule identifies potential path traversal vulnerabilities. In many cases, the constructed fi