Secure Coding Back to Basics - Erlend Oftedal - NDC Security 2022

In this talk we will go back a bit and discuss secure code.
We will look at the constructs we are using (and not using) and why changing some of the ways we typically write our code, can have security benefits. We will grab some elements from (modern) Domain Driven Design and see how we can use this to avoid or limit vulnerabilities.
Check out more of our featured speakers and talks at
ndcconferences...
ndc-security.com/

[@jbird4478]

"Data does not stay data. This is a bug." Exactly. So why are we still using the same crappy SQL language as we did 50 years ago? Why not use some binary protocol where data is never evaluated as commands?

[@jbird4478]

@@panosdotnet How it's stored is not related to the query language. The problem of SQL injection is that the app sends a command in the form of text to the database server. There is no distinction between the data and the command there, so data can accidentally be interpreted as a command. If you'd use a binary protocol for communicating with the server you could encode this distinction easily. Rather than letting the server pick one string of text apart, you'd just say "here's X bytes of data" and the server would know never to interpret those bytes as potential commands.

[@Hofer2304]

I have problems with duck typing. If you write a simple program, it is not a problem, but otherwise it is no help. I want to define my own domain specific types, and use them in a natural way. The best place for a type error detection is the editor. I have problems if nothing is really private. I want to declare my variables and constants, because I need as much help from the computer as possible.

[@capability-snob]

Wow I missed that trusted types (for innerHTML) thing the first time through. The policies are not a great API - it's spooky action at a distance - but it still seems worth switching that on.

[@Najumulsaqib]

Wonderful talk; you gave a unique perspective on secure coding which I havent heard before. Thanks

[@tactileslut]

No fault of the speaker but the video production was not laid out for legibility on the small screen.