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 Karlas 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 Karlas 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 wasnt 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.read
connection=Vertica.connect({
})
query=payload
output = Array.new
connection.query( query) do |row|
output.push row
end
connection.close
We can hardly say no, Karlas boss responded when advised of the risk.
What? Why not? Karla demanded.
Every customer is important to us. Kits 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 dont we just move his machine into our datacenter?Absolutely not! Are you insane? Sirel, the sysadmin, was just as adamant as Karlas 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. Its probably infested with trojans and keyloggers. I wont 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, Im sure.
Dave was in charge of Devops. It was his job to ensure that the code Karlas 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. Its an obvious security risk, Karla. No, more than that: the entire design is inherently unsecurable. Itd compromise everything else in our database cluster. Cant be done.
Come on, Dave. I know youre 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. Theres just no way. Nobody wants this thing in our environment. Well 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, Karlas boss outranked him; the code was put into production unchanged. Karlas boss didnt 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: its always better to be the client than the hapless souls supporting him.
| Комментировать | « Пред. запись — К дневнику — След. запись » | Страницы: [1] [Новые] |