Comodo “Chromodo” Browser disables same origin policy
code.google.com
code.google.com
"Hey, there's SQLi in this input form! Better make sure ' OR 1=1;-- is blacklisted," but don't properly parameterize their queries or sanitize input.
In case this is not clear to anyone in 2016, blacklisting known-dangerous characters is not an adequate bug fix. It's a rabbit hole, you will burn hours trying to blacklist every character or character combination that can cause a vulnerability just to have someone own you anyway.
Session Hijacking/Fixation/etc.: Use TLS.
SQL Injection: Prepared statements that AREN'T emulated; PHP's defaults are bad here.
EDIT: If you're writing in another language, make sure it's not providing string escaping masquerading as prepared statements, but actual prepared statements. (My earlier comment was too broad; some forms of emulated prepared statements might be OK, but PHP's is dangerous.)
Cross-Site Scripting: Context-aware escaping (templating libraries) + Security Headers
Cross-Site Request Forgery: CSRF tokens
Password storage: bcrypt, scrypt, PBKDF2-SHA2, Argon2
Encryption, Digital Signatures, Authenticated Key Exchanges, etc.: Hire an expert, don't do it yourself based on the advice contained within HN comments.
File Inclusion / Directory Traversal: Don't write your applications in a dumb way that makes these vulnerabilities possible. But if you must, use something like realpath() with a sanity check based on the expected parent directory (in PHP).
XML External Entities: Make sure you disable the entity loader:
libxml_disable_entity_loader(true);
PHP Object Injection in PHP 7: either disable object loading or whitelist the allowed types; i.e. unserialize($var, false); or unserialize($var, ['DateTime']);
These are just some of the common problems I frequently find, of course. There are more basic ways to mess up an application ("not even checking that you're authenticated" being at the top of that list).
https://paragonie.com/blog/2015/08/gentle-introduction-appli...
Further reading and resources:
* https://github.com/paragonie/awesome-appsec
And if anyone wants their code reviewed: https://paragonie.com/services
You can stop all known attacks with escaping, but then you run into fun corner cases like http://stackoverflow.com/a/12118602/2224584
What PHP does is silently perform string escaping for you instead of doing a prepared statement. This is stupid, but PHP Internals discussions are painful (so changing it is unlikely to happen any time soon) and the userland fix is easy:
https://github.com/paragonie/easydb/blob/f90fbca34ac7b7b96f7...
If you're sending a 1+N packets (for N >= 1) to your RDBMS for each new query, then you're probably using prepared statements.
execute("SELECT foo FROM bar WHERE baz = ?", [5])
db_socket ! encode_to_wire_format(
{'SELECT', "foo", "bar", [{'baz', 5}]}
))
Which is to say, if you (or your users) tried to put a fragment of SQL in place of the 5 above, it'd just get treated as string-typed data, rather than SQL. You don't need packet-level separation to achieve that.
But is this approach still bad for "emulating" prepared statements, somehow? I don't see how.
Sorry.
The answer to your question is: I don't know, that's a new solution to me.
It looks like it could be safe, but I'd have to dig into its internals to know for sure. My gut instinct is that it's probably safer than escape-and-concatenate.
If any Erlang experts want to chime in with their insight, please do.
EDIT:
> Which is to say, if you (or your users) tried to put a fragment of SQL in place of the 5 above, it'd just get treated as string-typed data, rather than SQL. You don't need packet-level separation to achieve that. > > But is this approach still bad for "emulating" prepared statements, somehow? I don't see how.
Above you said:
> the distinction between "tainted" user-generated data and the "trusted" statement is maintained
If this holds true, then you've still solved the data-instructions separation issue and what Erlang does is secure against SQL injection. So, yes, you don't need to send separate packets to ensure query string integrity in that instance.
The shit PHP does is what I meant to decry when I was talking about emulated prepared statements.
Thanks for broadening my horizons a bit. I've edited my earlier post. :)
Most environments don't have an implementation for it yet, and the ones that do will probably only get it through libsodium for the first few years.
> I've not heard of it until now, but the Wikipedia entry[1] shows that the paper was just released late last year.
Argon2 was the winner of the Password Hashing Competition, a several-year cryptography competition to find a new password hashing algorithm that would be secure against an attacker armed with a large GPU cluster.
The judges included a lot of famous cryptographers and security experts. Of particular note: Colin Percival, the author of scrypt, and Jens Steube, the project lead for hashcat.
I've read the paper and I think Argon2 will stand the test of time, but I could (of course) be wrong.
Most environments don't have an implementation for it yet
Disclaimer: I wrote the Ruby one.
When I started looking through the node bindings, I found a number of minor bugs and a critical issue that left ~1% of passwords vulnerable.
I trust that the C developers do a good job, but phc-winner-argon2 does not appear to have ever made a formal release. Is master really always perfect?
It's not ready yet.
Don't do it yourself.
Define X as the maximum time you can allow a hash to run on your server, before it either starts to annoy users, or becomes a DoS issue. Moving from "Argon2, such that it runs for X" to "both algorithms, with a total cost X" means both of them are running with a much reduced work strength.
In the case of Argon2, there is an "iterations" counter, but t=2 is already reasonable, and on low end hardware, you may see t=1. So as per the spec, reducing runtime in order to make whole thing work is going to involve reducing m.
Except bcrypt is already not memory hard, and you've just reduced the only memory constraint in your algorithm.
And entirely possible there are bigger issues I didn't up with two minutes of thinking about it.
If you just want to get data from A to B over the network, TLS 1.2 (but upgrade to 1.3 when it's ready). For an app(lication) where you control the code on both ends, with additional certificate pinning. Probably still worth hiring an expert to make sure you're doing it right but you have less chance of shooting yourself in the foot than if you try and roll your own.
Sometimes I think if cryptographers wrote libraries that the rest of us could use and "just work", security worldwide would improve. Bernstein's NaCl and the derived libsodium is a good starting point though.
Right. If you're not using TLS for your network communications, then your communications are not secure.
Some people also have other requirements (e.g. "I need to store SSNs, how can I encrypt them and still be able to search by them in MySQL?") which require separate app-layer crypto. In those situations, don't roll your own. :)
> Probably still worth hiring an expert to make sure you're doing it right but you have less chance of shooting yourself in the foot than if you try and roll your own.
Agreed.
> Sometimes I think if cryptographers wrote libraries that the rest of us could use and "just work", security worldwide would improve.
Ah yes, boring cryptography. :)
> Bernstein's NaCl and the derived libsodium is a good starting point though.
Strongly agreed.
>PHP Object Injection in PHP 7: either disable object loading or whitelist the allowed types; i.e. unserialize($var, false); or unserialize($var, ['DateTime']);
I'd stick to not unserializing user input in both cases, that's a can of worms you just don't want to open.
Also, RNG bugs are common and exploitable enough to be worth noting: Never use mt_rand, stick to openssl_random_pseudo_bytes.
Also, random_bytes() > openssl_random_pseudo_bytes() :P
Though if you use random_compat[1] it might be the same function ;)
Until now, when Tavis Ormandy decides to do this frustrating unpleasant work as a service to humanity.
3rd party browsers have also had an equal impact on the desktop security marketplace by competing with (and replacing) IE.
Similarly, "compliance" is a ritual executives perform because they have found it to have a calming effect on each other. Any relationship between corporate security activities with "being less vulnerable" is accidental - mostly it is about generating reams of paper to prove that the ritual is taking place. When a security consulting firm sells an audit to a business, it's not about fixing what the audit finds, it's about the ability to say "Well, such-and-such reputable firm did an audit so we did our jobs." If you're clever you can charge a clueless SME $100,000 just to pay your technician $15/hour for a 2-hour Nessus scan and give them an auto-generated PDF audit report recommending that they turn on Automatic Updates.
A very, very small subset of the security industry is actually engaged in making software or business processes harder to exploit.
They continue to make hundreds of millions of dollars, so they keep going.
Edit: are you talking about this: https://news.ycombinator.com/item?id=8866784 ? I'd have thought a company like whitehatsec would be able to do a better job with a browser.
This seems to be the trend in antivirus software (like the other gangbuster revelation with Trend Micro). They've slowly turned their software into the crapware they used to defend against in response to their increasing irrelevance.
I guess I'd have to manually install notaries and somehow verify their certs myself upon installation.
Edit: well I could rely on Firefox/Chrome to prebundle some "trusted" notaries' certs, like they do with CA certs now, but then I would be able to delete all but a few, contrary to the current situation where deleting some CA certs is breaking the internet.
Obviously a very different corner of the security landscape, but it doesn't seem like they've gotten any more careful.
Avoid.
Anyone have any suggestions for a free firewall alternative?
pf on OpenBSD. Strong firewall, highly configurable, the syntax isn't bad, and there are even some decent books out on it.
Sounds interesting but personally I'm sure I would get it wrong.
You can be pretty sure that none of their software is fit for purpose if they're not using basic protections for a process which runs as a super user and parses every file it can find.
{
command: "execCode",
code: "alert(document.cookie)",
}
obj.postMessage
https://developer.mozilla.org/docs/Web/API/Window/postMessag...
But, on the other side, it's a TRUE PITA to debug.