Software Security Fur All

- 14 min read - Text Only

The security industry is not too accessible. It focuses on common details, rather than fundamental problems and solutions. We can do better by building communities with free knowledge and compassion, rather than exclude newcomers with paywalled content and competitive hazing. Fundamentals like separating code and data must be top of mind as new technologies like large language models get deployed. Bad cryptography is everywhere and we hope to make cryptographic knowledge more accessible.

This talk summary is part of my DEF CON 31 series. The talks this year have sufficient depth to be shared independently and are separated for easier consumption.

Soatok is a furry security engineer. He often writes about cryptography, social issues that concern LGBTQ+ people, and security. Application security and cryptography became a core interest to Soatok when others repeatedly broke his websites long ago.

The written content between each slide is a retelling of my perspective on the subject matter Soatok presented. What I share is my own opinion and does not represent Soatok's views and opinions.

The presentation

Soatok began his presentation at the Furry DEF CON suite. It is an unofficial village with its own admission price, schedule, and presentations.

Title slide for Software Security Fur All by Soatok

Security is everyone's responsibility, and yet the software industry teaches security with ineffective techniques: check lists, industry requirements, common weaknesses and vulnerabilities — lists, lists, lists. Compliance mandates everyone gets educated, but educated with what? Those that regulate and assess compliance are not equipped to prescribe effective targeted education. And so implementers that use Java and JSON have to learn about PHP and XML vulnerabilities.

Sure, there's the way of thinking that educating people on the most common problems will prevent the proliferation of those problems, and industry guidance will change over time as the nature of product security changes. The flaw with this approach is how much cognitive overload everyone experiences. It's like we went back to school to learn how AVL trees are made, only to use standard library hash maps to poorly to cache certificate validation. The software industry is teaching security concepts that are not applicable to their applications.

How industry teaches security: checklists with owasp top 10; bug classes specific to technologies like XML external entities; and needless cognitive overload.

For those entering the software and security industry, there is a lot of noise to sift through. Search results are filled with outdated information, guesses, theories, outright fabrication, and search-engine-optimized lies.

Thank you, ChatGPT.

There are few highly-refined references freely available. Most academic material is bloated with theory that requires digesting multiple levels of references which are poorly communicated by authors lacking in empathy for the less informed.

Security certification institutions teach and test for trivial knowledge — after all, that's what job interviews and qualified security assessor need: people that can check boxes without understanding why something is important and whether it is relevant in the first place.

We are swamped with so much detail and complexity, which grows year by year, that insiders admit only lifelong learners will succeed in the security industry. Not everyone has this trait, and they should not need it to participate and improve security for individuals and organizations.

All this condenses to a systemic issue the security industry has: gate keeping.

Despite the economic slowdown, the security industry is still raising money (archived). It is a highly competitive space where the only incentives to improve security awareness are compliance, sales opportunities, or altruism.

I am a firm believer in sharing knowledge freely. Newcomers will happily consume free ChatGPT garbage rather than go through a paywall. If we want to raise security awareness for the many, it must be free.

To get the ISO 8601 specification from the source, part 1 and 2 cost in total $230 USD. This is absurd. The pervasive pay-to-play in the industry will continually harm its progress.

So bob why should we hire you. That's a dumb question. Welcome aboard! Shows a sign of stack overflow.

In addition to information being costly to acquire and use, there is a tendency to bully others online for ignorance, inexperience, or lack of context, as well as a lack of empathy for those less informed or in different circumstances. This is also gate keeping.

We need the opposite. We need freely-available information that is accessible to wider audiences, well-written, and written with compassion. Informative, actionable, and accessible content takes a lot of effort to prepare and share. We need more altruistic people to make security, cryptography, technology in general more accessible and humane. Less complexity would help too.

Yeet to gatekeeping. Focus on community. Knowledge and compassion should be shared. Start with fundamentals. Secure software not win a trivia game.

Several fundamentals are worth sharing to everybody, as they cut across languages, frameworks, and systems.

  • code and data must be separated
  • faulty logic can be a security flaw too, see Spoofing Certificates with MD5 Collisions
  • a secure product in an insecure environment is also insecure — see Log4Shell
  • client-side validation is not enough
  • the little details matter
  • follow the flows of information from start to end

Code vs Data

Code vs data example. Includes a query with inlined request information. Can be used to steal password hashes.

When applications mix code and data the worst strategy is to try to filter out potentially malicious inputs with a firewall or structured input sanitization. Filtering with regex can do more harm than good.

At least OWASP covers SQL injection. Soatok points out that because not everyone uses SQL, the more fundamental concept of code vs data should be taught instead.

Soatok then references "little bobby tables."

Instead of sanitizing inputs, they really should have been using prepared statements.
XKCD comic. Hi this is your sons school. We're having some computer trouble. Oh dear, did he break something? In a way; Did you really name your son Robert apostrophe right parenthesis semicolon drop table students semicolon dash dash? Oh yes. Little bobby tables we call him. Well, we've lost this year's student records. I hope you're happy. And I hope you've learned to sanitize your database inputs.

At that moment, I realized that Large Language Model jailbreaks are demonstrating the same issue all over again.

Will LLMs ever get prepared statements? How will that be accomplished?

Application logic and client validation

Client-side validation is necessary for a good user experience. The issue is when validation is only present on the client and not the server. Like, what if I try to access this URL for another person's resource as me? That is called broken access control, and is the number one issue tracked by OWASP.

Unlike injection being focused on SQL, OWASP got it right for broken access control. It is a fundamental concept that should be taught more and be considered in technical designs.

Twitter gender: bee movie script

Some bugs are so difficult to discover that we have to use automated discovery of unexpected behavior. This technique is called fuzz testing.

There is a fair amount of misunderstanding when it comes to fuzz testing. It is not some unit test you run for 30 minutes and if there's no issues you have a clean bill of health. Instead, infrastructure should continually test applications with varying inputs and mutations to find and report real but hard to find issues.

Computers are complex, and the programs we run are complex. We cannot explore the full range of application states in a few hours. Fuzz and mutation testing help us make the best use of our limited time and resources.


It wouldn't be a Soatalk without a section on cryptography.

Cryptography is amazing. Lots of blog post intros follow.

It is an area I am passionate about as well. I got things wrong and I want to do the right thing. A lot of security is like that too.

The details matter in cryptography, as it does with security. They matter a little too much.

Tried explaining danger of homebrew crypto to a journalist in DM "Cryptography is nightmare magic math that cares what kind of pen you use."
Should math care what kind of pen you use to implement it? No, but Fuck You, this is Cryptography.

The solutions we reach for are not always great, as well. Security is a constant mix of balancing risks and goals. Cryptography happens to be measurable in reality, while concepts like phishing involve humans where any measurement is flawed and biased.

i love reading papers/blogpoasts about proposed cryptographic systems/protocols whose first page makes me think "ok this smells too good to be true" and whose second page includes "reliance on Intel’s SGX"
Photo included with tweet

I've seen it. I've fixed it. I've written it. I've fixed that too. Bad cryptography is everywhere. With some education (especially from some of the talks presented at DEF CON) you can learn to spot bad cryptography too.

Bad crypto is everywhere.

Final thoughts

The security industry has a gate keeping problem. Its solution fails to equip people with checkbox security knowledge, and not the fundamental knowledge to apply and improve security.

To combat this, we need more empathetic people to teach and communicate fundamental security issues and solutions. These people should welcome more into the security community without presenting as competitive or superior to newcomers.

I share an interest with Soatok in cryptography. It is a challenging niche where every detail matters.

Soatok does his best to lead by example. I hope I set a positive example as well by making cryptography more accessible.