LWN: Comments on "Ubuntu forums compromised"

Ubuntu forums compromised

mathstuf — Tue, 26 Jul 2016 03:42:54 +0000

So he points to a shitty Java API which doesn't use proper typing (because doing that means you're a theoretician and we're about Getting Things Done™, damn any bugs it would make impossible, we'll patch them as they appear instead) and wonders whether PreparedStatement protects you against string concatenation bugs instead of whether it protects you when you use it properly. Of *course* Java APIs would suck with this: making proper types which act like a String except for things like concatenation with regular strings is a PITA in Java and no one does that. Either a troll or clueless, I hope he's just a troll and not actually writing code based on these beliefs.

Ubuntu forums compromised

Cyberax — Mon, 25 Jul 2016 23:25:59 +0000

And?

http://stackoverflow.com/questions/1582161/how-does-a-pre...
>"Due to one time compilation feature of PreparedStatement, it is free of SQL Injection attack."
> The SQL used in a PreparedStatement is precompiled on the driver. From that point on, the parameters are sent to the driver as literal values and not executable portions of SQL; thus no SQL can be injected using a parameter.

Ubuntu forums compromised

RogerOdle — Mon, 25 Jul 2016 23:22:11 +0000

See

http://stackoverflow.com/questions/4333015/does-the-prepa...

Ubuntu forums compromised

Cyberax — Mon, 25 Jul 2016 18:48:47 +0000

That's why serious companies write everything in paper notebooks with number 2 pencil (mechanical pencils are too dangerous).

Ubuntu forums compromised

Cyberax — Mon, 25 Jul 2016 18:35:21 +0000

> I do not have a solution. I am suggesting that the community find one. Since the "prepared statements" mechanism is one that can work independently of any particular server then there can be more shared support.
There is. Prepared statements are supported by all database abstraction layers (PDO, JDBC, ODBC, DBI and so on).

> You ask me to point at an example of a security failure. Why should I do that.
Because you're claiming that it's vulnerable.

> I looked at an implementation for prepared-statements and a simple analysis of the call interface shows that it is vulnerable.
Please, show your analysis.

Ubuntu forums compromised

mathstuf — Mon, 25 Jul 2016 18:22:02 +0000

Who proved to you that the database itself is trustworthy? I mean, it has to parse the SQL statement, build an execution plan, perform optimizations, and how many other things, so who knows what kind of problems could be present there, escaping or no.

Ubuntu forums compromised

RogerOdle — Mon, 25 Jul 2016 18:16:23 +0000

I do not have a solution. I am suggesting that the community find one. Since the "prepared statements" mechanism is one that can work independently of any particular server then there can be more shared support.

> Care to provide a reference to a real SQL server that has prepared statements that are vulnerable to SQL injection due to the lack of quoting?

You ask me to point at an example of a security failure. Why should I do that. I looked at an implementation for prepared-statements and a simple analysis of the call interface shows that it is vulnerable. So you have to trust what is under the hood. And it is different for every server. So you have to start from scratch when you determine whether it is trust worthy or now. But if you know that injection attacks will not pass your shared solution then you don't have to worry as much about the confidence level you have in your SQL server. It's about joining in common cause against a common form of failure.

I am not the kind of developer that leaves software open to injection attacks. I work in the embedded world on things where human life is at stake. We do software analysis very carefully and scour everything for problems. We may not trust Our software products can not be accepted without a careful chain of evidence that proves due diligence. Do you want me to trust your life on your non-solution? You provide no evidence that prepared-statements are trust worthy saying only "yes it is".

Ubuntu forums compromised

excors — Mon, 25 Jul 2016 17:12:44 +0000

> That said, filtering input fields is still a good idea due to the likes of XSS attacks, but that is entirely a different problem with very different filtering rules.

XSS attacks are almost always caused by concatenating strings containing HTML and strings containing user-provided data. That sounds exactly analogous to SQL injection attacks, which are caused by concatenating SQL strings and user-provided strings. Surely the solution should be the same: don't concatenate strings thinking you're being careful enough about adding escaping/filtering calls everywhere, because you'll inevitably forget one of those calls and it will be very hard to spot in code review or testing; instead use an API that clearly and explicitly separates syntax from data, like a sensibly-designed HTML templating library that defaults to escaping every variable you ask it to output.

Ubuntu forums compromised

flussence — Mon, 25 Jul 2016 16:43:06 +0000

>You're either trolling or...
Have to agree. I don't see how anyone can say concatenating strings together from arbitrary sources and then *evaling them as code* is safe with a straight face.

Ubuntu forums compromised

Cyberax — Mon, 25 Jul 2016 05:50:19 +0000

> My point is that there is no protection in prepared statements in and of themselves.
Yes, there is.

> You are completely dependent on the prepare-statement implementation that you are using. And they can not be uniformly trusted.
Care to provide a reference to a real SQL server that has prepared statements that are vulnerable to SQL injection due to the lack of quoting?

I'm not interested in spherical SQL servers in vacuum.

> If a developer is going to trust an SQL server for serious business, due diligence will require that the SQL servers provide proof of effective measures against injection attacks. They do not rely on popular fads like "prepared-statements".
You're either trolling or...

And anyway, it appears that developers like you are the reason for SQL injection. Instead of using a simple and effective way to prevent attacks, you're confabulating a reality that fits your hacky non-solution that will break after a first thorough inspection.

Ubuntu forums compromised

mathstuf — Mon, 25 Jul 2016 04:12:22 +0000

You're going to distrust a SQL server's implementation of escaping code, but not it's data integrity code, replication code, etc., which is orders of magnitude more complex? You think SQL server developers would test the latter and just "eh, it's probably fine" on the first? Odd choice of risk avoidance there. Not to mention that any server-agnostic library may need an update for any update of any supported server.

Ubuntu forums compromised

RogerOdle — Mon, 25 Jul 2016 03:56:54 +0000

My point is that there is no protection in prepared statements in and of themselves. You are completely dependent on the prepare-statement implementation that you are using. And they can not be uniformly trusted. You assert that they can be 100% trusted but where is the proof of that? Maybe the API for MySQL can be trusted but what about the next implementation? What proof is their that any can be trusted other than blind faith? You say they can be trusted but responsible developers do not trust. They are not allowed to. If a developer is going to trust an SQL server for serious business, due diligence will require that the SQL servers provide proof of effective measures against injection attacks. They do not rely on popular fads like "prepared-statements". I know that there is nothing inherent in prepared-statements that protect you from injection attacks. I believe that major SQL server developers have done their best and that most prepared-state implementations are probably safe. Major companies do not rely on probably's. Their lawyers wont let them. They need evidence that the prepared-statement system for SQL server XYZ does what it is supposed to do. An independent prepared-statement library could be a qualified interface between the developers and all of the SQL servers that you mentioned. It would be cheaper to certify than it would be to qualify all of the servers themselves.

Ubuntu forums compromised

pizza — Mon, 25 Jul 2016 01:14:39 +0000

> No, they don't. That's the whole freaking purpose of prepared statements. All practical DB engines (MySQL, PostgreSQL, MSSQL, Oracle, ...) provide protection against injection attacks in prepared statement arguments.

And your language/platform's database abstraction layer (eg Perl's DBI, PHP's PDO, ODBC, etc etc etc) all provide generic API calls that abstract away your particular database's low-level prepared statement APIs, so you can write your stuff in a generic manner and it'll work no matter what the underlying database is.

And, even if your DB doesn't support prepared statements natively, the platform DB abstraction layer will emulate them for you, automatically escaping the input so that it's correct.

That said, filtering input fields is still a good idea due to the likes of XSS attacks, but that is entirely a different problem with very different filtering rules.

Ubuntu forums compromised

Cyberax — Sun, 24 Jul 2016 22:52:38 +0000

> The input fields have be filtered to prevent injection.
No, they don't. That's the whole freaking purpose of prepared statements. All practical DB engines (MySQL, PostgreSQL, MSSQL, Oracle, ...) provide protection against injection attacks in prepared statement arguments.

Unless you do something stupid like using a placeholder value to construct sub-queries, prepared statements provide 100% protection against SQL injection.

I wish PHP developers would learn that one single piece of knowledge and stop producing SQL-injecty crap.

Ubuntu forums compromised

RogerOdle — Sun, 24 Jul 2016 22:31:25 +0000

Prepared-statements do not automatically protect you from anything. I have seen this term waved about like some kind of magic security talisman and the truth is that there is no standardization. The input fields have be filtered to prevent injection. The developer must know what the particular implementation of the "prepared statements" API does. Trusting it blindly would be foolish. A most basic implementation of prepared-statements would only formalize the mechanism for injection without any protection at all. We need tools that are carefully vetted for security purposes. Even prepared-statement systems must be tested thoroughly. I think that developers may like some kind of certification system. Using SQL to store names has been done for so long that there could be published a standard SQL filter for names say standard SQL-NAME-J100. If that standard is implemented in the prepared-statements API then it can be tested. Since the algorithm would be declared in a published standard, the developer would know what it does. If developers want to invent new name filters, let them; but I do not want to work at that level of detail. I am just an SQL user. If someone wants to provide a tool whose behavior is well defined then I am happy to use it. What I would like to see is a SQL agnostic library that does these things for whatever SQL engine I am using so that my input fields get treated exactly the same way regardless of whether I am using PosgreSQL, MySQL, or whatever. If that is a "prepared-statement" solution then that is fine.

Ubuntu forums compromised

micka — Sat, 23 Jul 2016 12:37:06 +0000

> in things like name fields, stripping special characters makes sense

I'd rather still ne able to write my own name though. What do you consider special? Anything not un a-z|A-Z|1-0?
Just for some my _latin_ language, you need diacritics, the minus character (actually hyphen), apostrophe.

Then you get someone who needs non latin characters, maybe with combining characters. You must build a table of all unicode space, with a flag telling if this character is allowed.

Ubuntu forums compromised

Cyberax — Fri, 22 Jul 2016 20:12:05 +0000

> There can be a SQL server agnostic solution
It's called "prepared statements" and they provide 100% protection from SQL injection.

Ubuntu forums compromised

Cyberax — Fri, 22 Jul 2016 20:11:03 +0000

There are people out there with apostrophes and double quotes in names. Should they switch to using SSNs for identification?

Ubuntu forums compromised

RogerOdle — Fri, 22 Jul 2016 19:28:52 +0000

Except that these server specific tools are non-standard and non-portable. There can be a SQL server agnostic solution so that these things do not need to be tied to a particular server API. If developers can use what they already know and do not have to adapt to the latest flavor of something they may be more inclined to use it.

Ubuntu forums compromised

pizza — Fri, 22 Jul 2016 17:26:11 +0000

> We would have a lot more confidence if there were common tools that do these things that can be vetted by the community than what we have now with everyone reinventing the wheel.

We don't need to invent new tools; we already have everything necessary. As eduperez mentioned, the correct approach is to utilize prepared statements with placeholders for user-supplied input.

Even if one doesn't use prepared statements, every database out there provides an API call that sanitizes strings so that they may be safely used.

Given that the fundamental problem is that developers aren't using the well-vetted tools/APIs that already exist, creating another one isn't going to solve anything.

Ubuntu forums compromised

RogerOdle — Fri, 22 Jul 2016 17:14:28 +0000

You have to think from a security point of view. If a form value requires a number then only numbers should be allowed. Filter out all characters that do not make sense. The hardest thing to handle is free-form text. But there you need a very advanced filter that is almost a SQL interpreter to detect injection patterns. But in things like name fields, stripping special characters makes sense, is powerful, and effective. Is there any library that handles the SQL injection filter/detector? We would have a lot more confidence if there were common tools that do these things that can be vetted by the community than what we have now with everyone reinventing the wheel.

Ubuntu forums compromised

eduperez — Fri, 22 Jul 2016 09:15:04 +0000

> My experience with SQL is that stopping SQL injection is trivial for web facing interfaces. Automatically strip all special characters from messages. Define your data domain so that characters like "=", "(", ")" are invalid.

Wrong approach, IMHO. You cannot strip all special characters from all queries without seriously limiting the functionality of your application. Sooner or later, you are going to have a text field where a semicolon or a quotation mark makes sense, and your method is going to break the application. Besides, you can always forget about some obscure method to inject a special character.

However, using prepared statements and placeholders, you can safely allow any special character on the text fields.

Ubuntu forums compromised

RogerOdle — Wed, 20 Jul 2016 17:46:06 +0000

My experience with SQL is that stopping SQL injection is trivial for web facing interfaces. Automatically strip all special characters from messages. Define your data domain so that characters like "=", "(", ")" are invalid.

So in what way was the website vulnerable? If I understand the article, user information was stored in the SQL database? This seems unwise and also unnecessary if a directory server is handy. I wonder what is considered "best practices" in this situation now for security purposes. What is the safest way to maintain internet user accounts for SQL supported websites?

Ubuntu forums compromised

lakeland — Tue, 19 Jul 2016 08:37:18 +0000

I was wondering the same thing.

To be honest, giving the web access to the tables mentioned sounds reasonable to me. What you'd need is something that monitors the database usage patterns of the application and identifies the unusual behaviour. There are products available which do that, it's called DAM, but they are to be a lot of effort to set up without false positives. I haven't seen any open source offerings.

Ubuntu forums compromised

thatva — Tue, 19 Jul 2016 01:02:30 +0000

Maildrop is a a free server for disposable email addresses that you can run on your own: https://github.com/m242/maildrop

Ubuntu forums compromised

anselm — Mon, 18 Jul 2016 20:42:26 +0000

This is all very sensible. The only problem with dash as recipient_delimiter is that the dash is something people reasonably expect to use in local parts of e-mail addresses without subaddressing, so using it as recipient_delimiter can be too restrictive – it may be OK if you're the only user, but I wouldn't want to do it on a mail server that is used by a larger group of people.

I like the idea of “locked” addresses as explained elsewhere in this thread. That would be worth looking into for a Postfix-based mail setup.

Ubuntu forums compromised

raven667 — Mon, 18 Jul 2016 15:36:51 +0000

That is the human tendency for extremely greedy pattern matching working its magic, the root of superstition.

Ubuntu forums compromised

drag — Mon, 18 Jul 2016 14:54:44 +0000

> Sometimes the delimiter is (also?) a dash

It can be anything you want. You just have to configure your email SMTP/IMAP/etc servers to use what you want.

I personally use underscores because people use that a lot when it comes to using email addresses so it's not something that can really be tested for on the spammer side. '+' are just too obvious, but I suspect it really doesn't matter a whole lot either way since it's not going to worth the spammer's time to deal with it either way.

Using subaddressing I have caught businesses that sell (or leak) emails to spammers in the past.

Ubuntu forums compromised

ballombe — Mon, 18 Jul 2016 12:26:50 +0000

The issues are in no way similar.

Ubuntu forums compromised

paxillus — Mon, 18 Jul 2016 10:31:14 +0000

prepared statements might help

Ubuntu forums compromised

job — Mon, 18 Jul 2016 10:12:35 +0000

You can change the recipient_delimiter in Postfix to something that bad web coders aren't as sensitive about. The (qmail default of) dash works pretty well. Modern Postfixes accepts a set of characters. The username I use for this delivers all mail to /dev/null for whitelisted extensions, as spammers will try to strip the extension (by malice or incompetence). I use a procmail rule but you could just as well set forward_path to something that includes $extension if you wish.

I only whitelist an address when I need to receive something, and remove it at the first unwanted mail. There's nothing to set up really, and it has worked well since pretty much forever.

Ubuntu forums compromised

talisein — Mon, 18 Jul 2016 07:04:30 +0000

Spamgourmet's software is on sourceforge, if thats the kind of thing you're looking for.

Ubuntu forums compromised

leoluk — Sun, 17 Jul 2016 22:03:08 +0000

Spammer strip those out nowadays.

Ubuntu forums compromised

lynxlynxlynx — Sun, 17 Jul 2016 20:37:08 +0000

It's called subaddressing and the userpart. Sometimes the delimiter is (also?) a dash. Great feature indeed!

Ubuntu forums compromised

dps — Sun, 17 Jul 2016 20:31:38 +0000

Did the server use sharply limited database identities to restrict what can be done even if the best efforts of the developer somehow don't eliminate SQL injection? If not why, why not? Almost any database server supports database identities with limited access and has done so for a long time. Many servers have additional controls, for example MySQL supports column level access controls, but database server agnostic programs unfortunately can't use those features.

Using new features, even if you know which database in use, is also difficult in commercial software because the deployment platform might not support them. The software I have in mind is intended to be a front end for a commercial service and unlikely ever to be sold.

Ubuntu forums compromised

anselm — Sun, 17 Jul 2016 19:15:47 +0000

Many if not most mail servers support addresses like foo+bar@example.com, which are handled like foo@example.com (you get to put whatever you like after the “+”, and don't have to tell the mail server). You can pre-sort mail based on the bit after the “+” using SIEVE, procmail, or whatever else you prefer. The main problem with this approach are anal-retentive web forms which don't think e-mail addresses should contain plus signs.

Ubuntu forums compromised

lucifargundam — Sun, 17 Jul 2016 12:37:05 +0000

I remember when Mint's iso was temporarily swapped... Is it me, or do these debian-based distros have similar problems?

Ubuntu forums compromised

dskoll — Sun, 17 Jul 2016 03:53:44 +0000

It's not free, but our CanIt software has a feature called "Locked Addresses". You generate a long random address and supply it to a web site that wants an email address. The very first email received by that address makes it "lock" to that domain. Once locked, if email comes from any other domain, the sender gets a "user unknown" error.

We also have tweaks such as the ability to lock to multiple domains, a complete audit trail of lock violations, and the ability to disable the address completely.

Although it's not free software, the idea is simple. A skilled programmer could probably make an implementation in a few days, so... there you go; an exercise for the reader.

Ubuntu forums compromised

k8to — Sun, 17 Jul 2016 01:28:40 +0000

A wildcard domain proxy is one way to get this functionality, which involves fairly little code.

But I haven't seen anything prefabricated as you inquire.

Ubuntu forums compromised

josh — Sat, 16 Jul 2016 21:43:42 +0000

I haven't seen a piece of software to make it wildly simpler than standard email server configuration.

Personally, I use email through my domain name provider, gandi.net, who provide SMTP and IMAP with every registered domain, including an arbitrary number of aliases and a web configuration UI for them.