With a capable static analyzer that is not true. In many common cases they can deduce the possible ranges of values based on branching checks along the data flow path, and if that range falls within the buffer then it does not report it.
I'm sure this is very interesting work, but can you tell me what targets they've been successful surfacing exploitable vulnerabilities on, and what the experience of generating that success looked like? I'm aware of the large literature on static analysis; I've spent most of my career in vulnerability research.
PREfix wasn't designed specifically for finding exploitable bugs - it was aimed somewhere in between Purify (runtime bug detection) and being a better lint.
One of the articles/papers I recall was that the big problem for PREfix when simulating the behaviour of code was the explosion in complexity if a given function had multiple paths through it (e.g. multiple if's/switch statements). PREfix had strategies to reduce the time spent in these highly complex functions.
If you say you need the data for security reasons that’s all well and good, but then you can only use the data for that specific purpose. So you cannot suddenly start using it for targeted advertising just because you already have the data.
This is just a random list of links to standards and summary tables, some of which are wrong (urandom vs. random, for instance). The "A/L/D" scoring makes very little sense. CBC is legacy-allowable and CTR is disallowed; "verification of padding must be performed in constant time". For reasons passing understanding, "MAC-then-encrypt" is legacy-allowable. They've deprecated the internally truncated SHA2's and kept the full-width ones (the internally truncated ones are more, not less secure). They've taken the time to formally disallow "MD5 and SHA1 based KDF functions". There's a long list of allowed FFDH groups. AES-CMAC is a recommended general-purpose message authenticator.
This is a mess, and I would actively steer people away from it.
It's a bad audit checklist! If OWASP volunteers can't do a good one, they should just not do one at all. It's fine for them not to cover things that are outside their expertise.
I’d wager that something like 90% of developers who look at that page should close the tab instead of reading any of it.
If you’re building a system and need crypto… pick the canonical library for the ecosystem or language you’re working in. Don’t try to build your own collection of primitives.
Also, I gave the link to the appendix because there was a specific question about Argon2 parameters. For general developer audiences, they need to look at the standard itself which is a lot more high level about how to properly implement cryptography in software:
https://github.com/OWASP/ASVS/blob/master/5.0/en/0x20-V11-Cr...
For the most common use-cases of cryptography like authentication and secure communication there is more specific, but still high level guidance that is useful for developers as well:
Yes I fully agree. I’m a big fan of libraries like Google Tink that make you pick a use case and use the best implementation for that use case with built in crypto agility.
Most crypto libraries are not built like that however. They just give you a big pile of primitives/algorithms to choose from. Then frameworks get built on top of that, not always taking into account best practices, and leave people that are serious about security the job of making sure the implementation is secure. This is the point where you need something like ASVS.
What language today still doesn't have a de facto simplified toolbox for wrapping crypto operations?
If you're a developer, and you start trying to perform crypto operations for your service and the library you chose is making you question which cipher, what KDF parameters, or what DH group you want, that is 100% a red flag and you should promptly stop using that crypto library.
Can you give some examples of such commonly used libraries for languages like Java / C# / C++?
In my experience there are not many libraries like Google Tink around, and they are not in widespread use at all. Most applications doing encryption manually for specific purposes still have the words AES, CBC, GCM, IV etc hardcoded in their source code.
If you review such code, it’s still useful to have resources that show industry best practices, but I agree that the gold standard is to not have these details in your own code at all.
If you only secure the login you will be sending your session cookies unencrypted for the other pages and they can be intercepted and used to impersonate you.
If the program has access to the credential, and the program is running on your computer, you also have access to the credential no matter how they try to obfuscate it.
What the game dev is supposed to do is have an account system on their backend, and ask the player to enter their credentials in the game. The game can then identify itself as this player to the backend servers. That way any actions on the backend can be attributed to a particular player and you have a good basis to make security decisions on.
Alas, no. ‘frame-ancestors’ does not work in meta. There is no reliable way to prevent click jacking if you are just editing the HTML. That makes sense: in order for these meta directives to even be enacted the HTML will have already begun to download and be parsed.
The old school way is comparing the top level URL with JS and redirecting but there are ways to deal with that
reply