When I interview developers, I generally ask some basic questions about security - "Explain to me what an XSS attack is?", or "How would you defend a web app against SQL injection?"
Basic stuff, which - to my mind - literally every person who develops anything which is on the web should know.
And a surprising number of people - even "senior" developers can't answer this stuff. It's really worrying.
I did a code review a while back with a new Web/Software Engineer II hire (I was not involved in the interview process) and noticed they were doing an HTTP GET request when they should have been doing a POST (attempting to change some values in the backend/database).
I talked to him about the issue, just chatting about GET, POST, PUT, etc...and all I got back was a deer-in-the-headlights look. He responded "I...I don't know what any of that is."
:(
I now ask "Can you explain what are some differences between an HTTP GET versus POST request?" with every web developer interview I do. If they get that one wrong or cannot answer...I don't bother with anything deeper.
I've been developing web apps since .NET 3, and the only thing I understand (and can claim to guard against [1]) in the OWASP top 10 is SQL injection. I always try to explain to my clients that web security is a complex field and they should hire a pro for that area... which, given that Google itself seems to have problems with it, is quite difficult.
[1] - claim, because you never know when someone happily calls exec_sql with a string from a stored procedure (had it happen at two different companies).
> I always try to explain to my clients that web security is a complex field and they should hire a pro for that area...
No. Just no.
Every other field of engineering includes security and safety as a core requirement of anything they do. Software engineering is no different, and while specialists can help, every engineer needs to know how to write secure code if we are to improve the sad situation the Internet is in.
Sell yourself as a software engineer who knows security, and watch the money rain as literally everyone tries to hire you.
> Sell yourself as a software engineer who knows security, and watch the money rain as literally everyone tries to hire you
How can you brag about the fact that a software engineer who knows security is worth more on the market, then try to claim that every engineer needs to know how to write highly secure code? Those are incompatible ideas.
A lock manufacturer designs locks. A carpenter designs the building the lock is securing.
You wouldn't rely on your carpenter to build you a lock, because you understand that they are two separate domains of knowledge. You need to have this same mindset about good security and good engineering.
Digital security requires a high amount of specialized knowledge and involves far more variables than lock construction. It also requires constant vigilance and integration, where as a lock is fire-and-forget.
> How can you brag about the fact that a software engineer who knows security is worth more on the market, then try to claim that every engineer needs to know how to write highly secure code? Those are incompatible ideas.
Software developers who have the abilities they should are more valuable than those who . . . don't. That doesn't seem controversial.
The abstraction doesn't fit. Where the civil engineers would be expected to build a bridge that doesn't collapse when the wind is Just Right (key word: Tacoma Narrows Bridge), software makers are expected to build a lock that doesn't open when someone whistles Just Right (key word: SQL injection).
Bridge builders are not expected to make the bridge itself defend against saboteurs, unlike software. To painfully extend the scenario: the wind is relatively well understood and once you've learned a lesson and guarded against it as a bridge builder, a given bridge can be considered stable.
Not so with software. One vuln fix, 5 more show up to take its place over time.
Malicious actors & botnets = the wind now (bear with me please). Once the bridge no longer collapsed via a certain Just Right tune, the wind would stop blowing the old Just Right way and instead try finding a new Just Right way, like whirling in a tight circular motion in just the right spot to see if it can unscrew bolts, or attempt -ddos- to tornado itself into a waterspout to try to collapose the bridge.
Do you expect a better answer for the second than "use a framework that parses the input in a way that escapes the input such that it's not interpreted as a command"?
Prepared statements tend to be the best answer for most cases which is similar to the approach you describe but is natively supported by most SQL dialects and also improves performance.
In my experience, many developers and even experienced security engineers can fail to give this answer though.
That's only relevant to know if you're actually implementing the piece that takes raw input and builds a query out of it, and most devs don't work with that piece on a day-to-day basis.
Knowing that you need to use a framework that takes care of input sanitizing is enough for the typical dev.
Edit: Expecting "prepared statements" as "the" answer seems close to making it a trivia question rather than "sufficient understand for doing the job" question.
I can forgive someone who can’t explain how XSS or CSRF works (I’m not sure I can explain it so clearly myself—kudos to the article’s author for the excellent explanation) if they know about the top 10 and have read it at least once.
I have almost succeeded Stripe CTF 2 (runed out of time on final step because of the crowd). I am sure I can not give clear definition during an interview without a good refresh before.
Basic stuff, which - to my mind - literally every person who develops anything which is on the web should know.
And a surprising number of people - even "senior" developers can't answer this stuff. It's really worrying.