nupark

- In the first, the API design itself made it non-obvious/easy to directly concatenate strings while -- at a glance -- appearing to be correct.

- In the second, the API's implementation resulted in SQL injection because :limit and :offset arguments were not correctly escaped.

- In the third, the API's documentation and recommended usage (in 2004) encouraged users to use constructs that appeared to provide defense against SQL injection, but in reality, did not.

The last time I researched this, I started here:

http://www.google.com/search?sourceid=chrome&ie=UTF-8...

... would up and sources like this:

http://lists.rubyonrails.org/pipermail/rails/2004-December/0...

... and spent a good hour reading the Rails source code. My take away was that, historically, a lack of care coupled with a lack of use of the parameterized APIs left the door open to repeated failures in the implementation to protect against SQL injection.

Things have improved in Rails, but as a historical example of the pitfalls of ignoring/eschewing parameterized query APIs, I believe it to be quite valid.

The discussion at hand is, "who's job is it to defend against SQLI, the database, the framework, or the application?". Of those three components, the database is least well equipped to defend against SQLI. SQLI is "avenue for attacker to submit queries to a database contrary to the intentions of the application". The database's simple job is to accept and execute queries.

No, you're reframing the discussion. The original poster commented on MySQL's longtime begrudging support for parameterized queries (or lack thereof) as one of the major causes of the prevalence of SQL injection issues.

It seems clear to me that the database -- as the central implementation responsible for parsing queries -- is the best equipped to provide safe, correct string interpolation of those queries.

The database is the normative reference on what is and is not a special cased character and how escaping should be implemented. I don't think it's reasonable to assert that escaping is a concern that should be adopted by every framework that might ever talk to a database.

The examples you've provided of Rails SQLI issues are bad ones

I'm sure you could supply some better examples since your focus is in security, and there are a vast number of issues that have arisen in ActiveRecord's escaping (especially in early versions of Rails). These are merely what I quickly found while Googling.

The first is a discussion of SQLI in an interface designed to accept raw SQL; it's the ActiveRecord "back door" interface.

It's also an interface that was repeatedly and unintentionally used by Rails users to insert unescaped queries in a way that did not immediately appear incorrect, as evidenced by the preponderance of questions on the subject.

The second is a discussion of SQLI in a context where parameterized queries don't work anyways (the MySQL protocol doesn't accept LIMIT and OFFSET arguments as anything but integer constants); it is also the simplest of the class of SQLI concern areas (you can solve it by blindly calling #to_i on your inputs), which also includes table names, sort orders, and column references.

Given that this conversation is occurring in the context of discussing how MySQL's design has led to exactly these types of errors, I think this is an applicable example.

As for them being required -- you can obviously escape queries yourself, but the normative reference for escaping is the target database itself, and reproducing escaping locally in the client brings with it the likelihood of introducing an error in the custom implementation.

This means that every protocol client must implement their own query escaping, rather than relying on the database to provide a single, normative implementation of escaping.

> For example Ruby on Rails's ActiveRecord provides an API that looks a lot like it uses parameterization under the hood:

ActiveRecord's use of the non-parameterized APIs has led to a number of escaping/injection issues in the past eg, (http://www.ruby-forum.com/topic/152058, http://gsa.ca.com/vulninfo/vuln.aspx?id=36929, etc).

> If you think stored procedures protect you against SQL injection, consider the following code snippet ...

I believe the original poster was referring to the use of stored procedures as a mechanism for preventing or discouraging unintended direct modification of the database by applications, rather than SQL injection, specifically.

If you switch to the JVM, a buffer overflow triggers determinate behavior -- it throws an exception rather than writing over the saved return address or the heap.

The attack surface is by it's nature is much smaller than if you rely on programmer correctness in C.

As for inserting tags "dynamically," this sounds like a broken templating system if that means exposing the programmer to fail-fast (instead of fail-safe) escaping APIs.

Actually, the fix isn't to stop making mistakes. The fix is to stop using APIs and/or runtimes that make it easy to make mistakes. Design your APIs such that buffer overflows aren't possible.

The same thing applies to web development and escaping of output data. In a proper API, it should literally not be possible to accidentally write unescaped data to the page.

I don't install new desktop apps very often because my needs are already solved. I do nearly all my work in:

- Mail.app

- Xcode

- Eclipse

- TeXShop

- Terminal

- Chrome (JIRA, and browsing documents-not-webapps)

I'd prefer a native application for JIRA, but I haven't found a decent one yet.

Same is true for mobile, I don't see another space for innovation except improving web performance, integration & so on. Maybe you see some other directions where iPhone & Android can go?

I expect the iOS and Android platforms to continue to evolve their core libraries, providing significant additional functionality and features for use by mobile applications. Eventually that will slow as the mobile platforms mature.

I'd like to say that I expect the development of higher-level common platforms out of web browsers, but outside of (possibly) WebOS, this seems unlikely.

Compared to the web, iOS and Android have comprehensive platform APIs with consistent widgets and user experiences (iOS more than Android when it comes to consistency), support for multiple programming languages and runtimes, immediate access to platform vendor's APIs (playing video doesn't involve an browser vendors arguing over <video>, etc.

My organization works in a variety of languages/runtimes, from ObjC to C to assembly to the JVM. We do web, mobile, server, and OS development -- whatever is needed.

I was in a meeting recently discussing complex image processing we had implemented in C++ using OpenCV. We considered OpenCV and C++ to be the best tools for the specific job at hand, which is why we chose them over the alternatives.

A life-long Flash developer -- who has a heavy investment in Flash remaining relevant in his organization -- chimed in to tell us that Flash can do the same thing, and there was no reason to use C++. In theory, we could have made Flash do our bidding, but it was the wrong tool for the job, and we quite intentionally didn't use it.

Web developers seem to apply the same logic as this Flash developer to the development of native apps. There's a much shorter description for this:

When all you have is a hammer, every problem looks like a nail.

The full set of articles: http://stuytownluxliving.com/cgi-bin/mt-search.cgi?blog_id=1...

Yes. In the late 90s, I worked in security for a company that ran one of the largest (at the time) shared hosting providers.

do you really think all of those servers have been rooted?

If someone was interested enough to capture an administrator's user account, then yes, they have been rooted.

if your operating system has no local user security, you should really upgrade it or switch to a different operating system.

There's no such thing. The local user attack surface is just too large.

As related to sudo, it's silly to think that local OS security can protect you from someone with access to an administrator's shell -- even if using sudo requires a password.

Let me break this down into simple steps:

Scenario 1:

- I acquire access to your password.

- I log in as you, then use your password to sudo to root. Game over.

Scenario 2:

- I acquire access to your SSH key or an active terminal on your server. I do not have your password.

- Logged in as you, I notice that sudo requires your password.

- Since you use zsh, I add the following to your zshrc:

  sudo () { /usr/bin/sudo sh -c "echo \"pwned. Game over.\" && $==*" }

  nupark@fish:~> sudo ls /var/cores
  Password:
  pwned. Game over.
  tar-3493.core
  nupark@fish:~>

Once someone has a local shell -- especially an administrator's shell -- the machine is effectively compromised.

Requiring a password for sudo is at best a minor speed bump, not an obstacle, and it results in the propagation of password usage throughout your infrastructure. Many of those passwords, once acquired by an attacher, will likely grant access to other, possibly more critical systems.

  alias sudo="sudo and do something evil instead"

Once you have access to a local shell, the game is over. Acquiring root is easy, between local exploits or simply piggybacking on (or sniffing) a valid, passworded sudo login.

As to the rest; my point was that Bertrand was very opposed to change in 'his' code, not that he wasn't open to any change. Regarding malloc, I think Bertrand still thought he'd be best suited to do it, and he has always objected strenuously to others approaching his problems.

Oh, and as for top…when they did change it in early SnowLeopard builds, it broke a whole host of tooling, etc., and they had to revert some changes...

That's pretty normal when tools depend on text output of commands (something Core OS has told everyone not to do, and then they do anyway). The initial conversion to modern top/libtop actually occurred back in the 10.{1,2,3} release cycles, and was subject to a very heavy amount of push-back and compromise with Bertrand about "his" top(1) :)

However, Serlet, despite no longer writing code, was incredibly stubborn about any changes to his pet implementations, even 10-20 years later. This included large changes, such as updating malloc to a more modern implementation (see Jason Evan's later work on jemalloc), and small changes, such as updating top(1) to better match its Linux and BSD counterparts and implement a standardized library (libtop) for accessing process/host statistics (he wrote top, too).

Serlet was like many technical individuals that graduated into fulltime management; stuck with the last technology they'd worked on, as it was when they last worked on it. Avie was the same with his fixation on Mach, and Mac OS X was honestly poorer for it.

This is no different than anything else in life, from job applications to pitching a client, and the world hasn't changed as much as you seem to imply.

People (like myself, and I believe the original poster) take issue with the use of 'hustler' because we see clear parallels between the negative connotations of the term and those individuals that self-identity with it.

http://www.google.com/search?sourceid=chrome&ie=UTF-8...

I have a hard time with the notion that web apps should be "stateless." It seems to be an argument borne out of limitations of the frameworks/platforms being used, and repudiated by the fact that such platforms do share state, but are forced to use less efficient external mechanisms (such as network requests to memcached, the local database, etc), rather than leveraging the advantages of data locality as available in a non-multiprocess system.

We've often taken advantage of sticky sessions to allow individual servers to maintain and share state across requests while ensuring that the state could be reconstructed by another server should it become necessary. It is simply more efficient to do so, and efficiency in implementation directly translates to dollars spent on operational costs, as well as effects on human observable response times.

Everything from database connections to user data can be cached locally, shared across connections, and does not require multiple processes each with their own large heap.

I'd like to elaborate on more examples (such as comet and efficient handling of a large number of blocked connections while allowing unblocked connections to proceed concurrently while maintaining cached local state) ... But I'm on an iPad and this keyboard is driving me crazy.

If it was as easy as you seem to think, we probably wouldn't introduce such bugs by accident in the first place.

It can be as innocuous looking as using strncpy instead of strlcpy.

I really hate this argument for its disingenuity. Some things (including message passing) are naturally fastest with shared memory. Multiple processes are not an equivalent substitute.

Clojure, for instance, leverages shared memory to implement its excellent, lightweight STM and related high-level threading constructs, and shared memory is what allows Clojure to easily implement cheap, MVCC functional data structures.

Multiple processes aren't an answer, here. To implement the same high-level constructs efficiently requires re-introducing shared memory through more complex, less efficient mechanisms, and often leaves the problem of sharing access to higher-level constructs (objects, instead of data) unsolved.

Multiple processes are a poor work-around for a lack of support for concurrency, not a solution. They make sense if you're sandboxing, but make little sense for implementing a high-performance concurrent server.

To pre-empt the erlang discussion -- erlang's message passing model does scale, but Erlang's runtime does require support for real shared memory concurrency in order to maximize single-machine performance.

Unintentionally malicious additions slip through all the time: they're called bugs.

http://twitter.com/#!/therealkerni/status/48341474210881536

We don't have much of a history to work from, and the majority of the enabling tools available to us simple did not exist prior to or during the emergence of the current economic and business environment.

I think developments such as Kickstarter provide a glimmer of where things are headed.

With a sufficiently large lifestyle-driven economy, we could move away from the VC model where very few people have the majority of the capital necessary to fund big ideas.

We're already moving to a world where industrial costs continue to decrease, small businesses specialize in providing specific services (such as manufacturing), and computers and machines provide enormous leverage. Examples range from Amazon EC2 to affordable, low-scale manufacturing of injection molded plastics and cheap, on-demand PCB manufacturing.

On the subject of building "big things", it's worth reading this blog post on how the Glif (http://www.theglif.com/) was created by a small team of two, funded by Kickstarter, from design to manufacturing: http://www.therussiansusedapencil.com/post/2794775825/idea-t...

In comparison to pg's example of a router, it is a small thing, but it's a great demonstration of how the bar is being lowered, and what was only accessible to large, capital-rich entities is now available to two guys with limited initial capital.

pg: Did they explain the long-term goal of being the market in accommodation the way eBay is in stuff? That seems like it would be huge. Hotels now are like airlines in the 1970s before they figured out how to increase their load factors.

fw: So I think it can scale all the way to the bed and breakfast market. But I am not sure they can take on the hotel market.

The problem is, the regulatory system (not to mention the neighbors) do not want unlicensed, widespread "crowd-sourced" illegal hotel rooms, and are working hard to block them:

http://www.frommers.com/articles/6912.html

Paul Graham talks about the 'eBay' of accommodation -- but a huge percentage of eBay's revenue comes from professional sellers, which is exactly what will run afoul of regulation in the rental/hotel market.