Hot answers tagged

49

I think you are correct that those issues are more related to code quality rather than security, and none of them are exploitable in any obvious way. I would not call them "vulnerabilities". But vulnerabilities are born out of bugs, and bugs are born out of bad code quality. Bad error handling could lead to unexpected results - i.e. a bug - and if you are ...


25

If it's an official service you are integrating with the provider should really have a valid, publicly signed certificate installed for the sake of security. Assuming that you need to continue on with your provider using a self signed certificate, the big difference between ignoring the certificate and adding it as trusted is the following scenario. This ...


16

By importing a known good self-signed certificate where the private key is unique and not compromised, the connection is just as safe as a full global CA PKI signed certificate. Those are after all also simply stored and trusted at some point. The reason to get a PKI CA signed cert is one of practicality more than security; if you have to trust a self-...


11

How are these related to security? According to my understanding it seems like the above issues are code quality issues. These are code quality issues. From the name, it looks like they are straight out of Fortify. Fortify has the ability to look for code quality issues and it looks like your security team enabled those rules while running the scans. ...


5

I have been dealing with code audits, security analysis like this one and ethical hacking runs for a decade and a half now, so let me share some of my experience. Every single boss and team lead I've had that I saw as a role model insisted on haviing high standards for code quality, not just to make code reviews easier but also in name of stability, ...


5

Bad guys start an attack by learning as much as possible about the target system. An improperly handled exception can reveal sensitive information to the calling client. In a REST API for example, a typical successful GET response would include requested object and a 200 HTTP status code, but little else about the server implementation. A response for a ...


4

This isn't even remotely close to safe. There are any number of gotchas: As pointed out by Anders in a comment, this can be easily bypassed by injecting in \'. This works because it escapes your backslash, turning it into a literal backslash and causing the single quote to become unescaped. Moreover, this is actually a very common thing to attempt ...


3

If you ignore the certificate check, anyone who can gain the man-in-the-middle position (with the ability to modify traffic) between you and the other system can read/modify the plain-text traffic. An attacker will simply break the TLS/SSL tunnel by starting his own TLS server using his self-signed certificate, route your traffic to it, decrypt it, and proxy ...


3

Insecure deserialization is not a Java specific flaw, all languages are subject to this kind of vulnerability. Please have a look at this 2017 blackhat conference : Friday the 13th: JSON attacks, it focuses on .Net JSON serializers. You can find a useful tool to test your developments in yoserial. Regarding XXE, it has nothing to do with serialization, ...


3

According to Oracle JRE and JDK Cryptographic Roadmap Symantec Root CAs will be removed in April 2019 release: Date: 2019-04-16 Releases: 12, 11, 8, 7 Action: Distrust TLS server certificates anchored by Symantec Root CAs.


3

Before I answer your questions, here are a few principles that will make the answers easier to understand. Keep network usage to a minimum. All transmissions are vulnerabilities. You are using the network to synchronize passwords between devices. All of the other functions should be performed locally on a cached database. Sensitive data should stay ...


3

Yes, your filtering on userinput2 is insufficient, the use of a single quote is not necessary for exploitation with that syntax. I didn't analyse the code any further. "Blacklisting" characters is not a reliable defense against SQL injection. You should alter the code to use parameterized queries instead.


2

I've been using Amazon Web Services to run my Java application. However, due to high costs I'm looking into getting a dedicated server from Hetzner... I'm concerned that anyone with physical access to my server could steal my data/application... In other words, unless I have complete trust in the people who run the company to secure physical access ...


2

My intention was to hash password in HTTP request body and only compare the strings on server side. Does it makes sense from security point of view? Not really. While it makes it harder for someone to gain the clear text password, they don't have to. But an attacker won't have to care about the password. They can pass the hash. The hash is effectively the ...


2

If we accept that SecureRandom is a true random then the expected collision for IV is given by the birthday paradox is sqrt(2^96) = 2^48. Your daily message is 2^24 and this will have a very low collision probability. You will have 6.783914×10-16 chance of collision probability for the day. However, once the collision occurs we have IV reuse. IV reuse is ...


2

Focusing solely on the (claimed) security benefits. There are multiple elements to this. I'll address each in turn. Robustness against attacks that utilise malformed requests. The thinking here is that the reverse proxy does a better job of rejecting malformed requests and therefore does a better job of defending against attacks that depend on the server ...


2

It depends on the backend. If the application logic validates on submit, there's no problem. The developers must implement server-side checks, because bypassing client-side protection is trivial, as the example you saw. Client-side validation must be used only for avoid losing client time. Any and every client-side protection can be easily bypassed. ...


2

Based on the Bouncy Castle user guide, you can definitely update the security providers list to include BC FIPS. As the JSSE requires the presence of the SUN provider in FIPS mode, the minimal static provider configuration to support the JSSE is: security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider security.provider.2=com....


2

Transmitting data over TLS is assumed to be secure when the TLS implementation is well-managed. There are three major developer-level considerations. Your server and client should be configured only with secure ciphers. Some MITM attacks leverage server/client support for weak ciphers to force the selection of a weak cipher, which the attacker then ...


2

In the quote you added: Vulnerability in the Java SE, Java SE Embedded component of Oracle Java SE (subcomponent: Networking). Supported versions that are affected are Java SE: 7u221, 8u212, 11.0.3 and 12.0.1; Java SE Embedded: 8u211. Added emphasis is mine. You can be pretty safe in assuming that previous updates in there are affected by the ...


2

These kind of code quality issues may lead to security issues depending how it's implemented. That's the reason why we have SAST tools in placed to detect this kind of issues at early stage of development. You need to improve your error handling.


2

Using Java or Python instead of C or C++ does indeed (almost) completely remove the risk of buffer overflows and similar. That does not automatically make such services safe or even safer - there are whole classes of vulnerabilities (check out OWASP top 10) completely unrelated to memory safety. So would writing an OS in Python of Java be a good idea? It's ...


2

DESede/ECB/PKCS5Padding DES is already broken and TDES is created to use until a new cipher is developed, called now AES. The block size of DES or TDES is 64-bit and this is insecure, see Sweet32. ECB mode for block ciphers, forget about it. It is not even a mode of operation. It reveals a pattern in your data. See the penguin on Wikipedia. In some case ...


1

Well, unsure for Java, but the standard Python implementation is called C-Python and is written in C language. So (if it was even possible) an OS written in Python would ultimately be built using C. Moreover, when we think of programming languages, most are targetted at writing applications, not OS and programmers rely on the language implementation to ...


1

Memory safety is very common source of vulnerabilities and completely avoidable. Clearly it should go. However, there are many other ways to make software unsafe that memory-safety does not directly address. 100% Pure Java was a Sun trademark and marketing campaign. It required applications to be unusably platform independent. Clearly there is a need for at ...


1

I would not consider it XSS vulnerability, as SOAP services are usually called by another service that would not execute anything in the response. However you could address it by validating the namespace and throwing a more generic error without including any contents from the payload. Trying to encode it differently is just creating a moving target and ...


1

I'll take a guess... parsing the regular expression, it appears to be matching: Anything (optional) . OR ^ OR anything OR [ Quote (single or double) The literal string class (case insensitive for the c only) . OR quote (single or double) ] OR [ Anything (optional) I'm not 100% sure on this. Sometimes the precedence rules are tricky, and I can't easily ...


1

Certificates are the way that the signer can vouch for the signee. If you trust the signer, then you can trust the certificate and the signed public key. If you trust the signee, you can ignore the certificate. In more real world terms: Example 1: Cindy Certificateauthority is very well known. Everyone knows Cindy. Cindy has a really good reputation ...


1

You should never write an implementation to an existing algorithm or design an algorithm. The algorithm should be picked up from a book and implementation from a library. Keeping the above points in mind, remember that Diffie Hellman is vulnerable to MITM attacks as there is no authentication factor involved in the protocol. For confidentiality, I would ...


1

However, let's say your json deserializaer (or whatever) is securely configured. Is it possible to create gadget chains which re-configure jackson at runtime to be insecurely configured? The presumption in your question here is that the vulnerability in Jackson (or whatever) would be merely a matter of poor configuration. Usually, such vulnerabilities are ...


Only top voted, non community-wiki answers of a minimum length are eligible