Injection By Design
As web developers, we spend a fair amount of time protecting our valuable server resources from the grasping tentacles of Internet ruffians and malfeasants. Occasionally, we're tasked with exposing data endpoints to the public Internet. This is generally a carefully crafted solution of whitelists, authentication, authorization, escaping input, limiting access and other protective measures.
But we are not, and cannot be, the domain experts for the system. There is always an inherit tension between our area of expertise, namely software development, and the needs of our business users for their own purposes. Never is this more true than when the problem domain is something that borders on our own area of expertise.
Kit was a quantitative analyst; he knew enough Ruby to be dangerous, but nothing of software engineering as a discipline. Nevertheless, his understanding of the problem domain was deep and thorough. He knew what he needed to accomplish, and enough of how to do so that all he required from Karla's company was server maintenance for his analysis and the accompanying "big data" SQL database. He was spending more time than he wanted to be administrating the machine sitting in his closet. Since his group had an existing relationship with Karla's company, it made sense to delegate to her team.
Karla was tasked with examining the code to ensure it would pose no threat to their other existing clients. The code was typical of new programmers who understand the problem better than the solution: inconsistently spaced, with a coding style that matched no known format, and weak in places-but it would work, and it wasn't just a rootkit disguised as an app. Karla was about to advise accepting the code when something caught her eye: it was designed to take in POST requests and execute them as dynamic SQL queries.
post "/" do content_type :json payload=request.body.readconnection=Vertica.connect({<redacted>}) query=payloadoutput = Array.newconnection.query( query) do |row| output.push row endconnection.close"We can hardly say no," Karla's boss responded when advised of the risk.
"What? Why not?" Karla demanded.
"Every customer is important to us. Kit's group does millions of dollars of business with us annually."
Ah, yes. Every customer was equal, but the spendiest ones were the most equal.
"We need to make this work," the boss continued. "Why don't we just move his machine into our datacenter?""Absolutely not! Are you insane?" Sirel, the sysadmin, was just as adamant as Karla's boss. "You want to install some random piece of kit into my datacenter? For all we know, this has been sitting on his desk, talking to God-knows-what. It's probably infested with trojans and keyloggers. I won't have it in my nice clean network!"
"Okay, but the boss wants us to help this guy," Karla pointed out, feeling a bit desperate.
"So take it to Dave," Sirel said. "He can figure something out, I'm sure."
Dave was in charge of Devops. It was his job to ensure that the code Karla's team developed was deployed and maintained in their environment. If anyone could make this walking time-bomb play nicely with their existing environment, Dave could.
He, of course, was having nothing of this either. "It's an obvious security risk, Karla. No, more than that: the entire design is inherently unsecurable. It'd compromise everything else in our database cluster. Can't be done."
"Come on, Dave. I know you're good at this stuff," Karla pleaded.
"Just last week, I promoted a SQL injection risk your team let past code review," Dave countered. "It took me three days to track down. Do you even understand how many alarm bells were going off? I'd be skinned alive if I let you put this into prod."
Karla trudged back to her boss. "There's just no way. Nobody wants this thing in our environment. We'll have to refuse until Kit can find a more secure way to implement it."
"Nonsense!" the boss cried. "The customer wants it, and the customer is always right!"
Dave fought long and hard, but in the end, Karla's boss outranked him; the code was put into production unchanged. Karla's boss didn't even have the decency to buy Dave a drink first-though he did manage to look surprised when Dave left six months later to pursue a career in finance instead. You see, Dave had learned a valuable lesson: it's always better to be the client than the hapless souls supporting him.
[Advertisement] Easily create complex server configurations and orchestrations using both the intuitive, drag-and-drop editor and the text/script editor. Find out more and download today!