Introduction

Today I'm proud to announce a first-of-its-kind web security course. Spanning 12 intensive weeks, this course goes well beyond what's possible in traditional trainings and will transform you into a web security professional.

Note: this is not in any way affiliated with my employer.

Goal

My goal with this course is to take you from web developer to web security professional. You will know common (and uncommon) vulnerabilities, how to discover them, how to exploit them, and how to protect against them.

By the end of the 12-week course, you will be in a good position to build secure products, work as a security consultant, and generally break everything that comes across your desk.

There are no written tests or fill-in-the-blanks homework. Every exam is a practical one and you will be finding bugs from day one.

Security professionals are more in demand than ever; whether you're looking to move up as a developer or jump into the security field, you will get your money's worth.

Upon successful completion of the course, I will -- if you opt-in -- personally refer you to several of the top security consultancies in the world. You will be the perfect candidate!

Prerequisites

• You are a developer with experience working on and with web applications.
• You understand HTML and can read and write Javascript well.
• You know at least one of {PHP, Python, Ruby, Java} and can read and understand web applications written in them.

What to expect

As mentioned before, you will be finding bugs on day one. You can expect 2-4 hours of course work in the week following each class and 3-4 practical exams throughout the course. Your success in this course is highly dependent upon completing the assigned work in a timely fashion, due to the depth and breadth covered.

If you start to get in the weeds or just have some questions, I'll be available to help you out and get you back on track. You'll also have access to private forums for students, and an IRC channel in which to discuss problems.

Syllabus

Week 1

The first week, we start with an introduction to the course and end with you finding your very first bug. This sets the pace for the rest of the course.

• Introduction
  • Structure of the course
  • How to contact me
  • Resources
• General introduction to security
  • How to think like a breaker
  • How to write up security findings
• Tools and setup
• Your first bug

Week 2

In this week, we will discuss how browsers work, from the ground up. This will give you insight into how you can violate trust boundaries and lead us right into breaking web applications. You'll also learn about cross-site request forgery (CSRF) attacks, one of the most common you will find in applications today.

• HTTP requests
  • What they look like and what the contain
  • How cookies work
• HTML
  • How it's parsed
  • How legacy code in browsers helps attackers
• Javascript and DOM
  • How Javascript runs
  • How the DOM works
• Content-type sniffing overview
• Encoding overview
• Same-origin policy
• Cross-Site Request Forgery

Week 3

In this week, we'll dive in with several common, severe vulnerabilities. We'll examine real-world cases with a focus on how to discover them, how to exploit them, and how to mitigate them.

• Forced browsing
• Directory traversal
• Improper authorization
• Authentication bypasses

Week 4

In this week, we'll discuss in-depth two of the most common and crippling vulnerabilities found in web applications today. You'll learn discovery and exploitation techniques as well as mitigations.

• Cross-Site Scripting
  • Reflected
  • Stored
  • DOM
  • Common protections and how they fail
• SQL Injection
  • Typical
    • Discovery
    • Exploitation
  • Blind
    • Discovery
    • Exploitation
      • Tools

Week 5

In this week, we will discuss several vulnerabilities with far-reaching consequences for web applications. Command injection will be a focal point, wherein you will learn how to bypass standard protection mechanisms and see how subtle bugs can lead to major bugs in real-world applications. You'll also get an introduction to testing web services and web APIs.

• Clickjacking
• Command injection
• Cookie tampering
• Session fixation
• Testing web services/APIs
  • REST
  • SOAP
  • JSONP

Week 6

In this week, you will learn how to turn an application's logic against itself, enabling you to read and write files, execute your own code on the webserver, and more.

• Arbitrary file reads/writes
• Local and remote file inclusion
• File upload flaws
• Unchecked redirects

Week 7

In this week, we'll discuss how to effectively review source code, an invaluable tool in the security professional's skillset.

• Source code auditing
  • What you can reasonably expect to accomplish
  • Tools
  • Tracking coverage
  • Entrypoint tracing

Week 8

This week will focus on how to think through secure design and architecture, identify threats, and enable more secure development.

• Threat modeling
  • What it is
  • Why it's useful
  • Why full threat modeling is a waste of time for consultants
• Secure design
  • Questions to ask
  • Red flags
  • Supporting legacy designs

Week 9

In this week, we will discuss securely storing passwords -- and what's possible when this is not done -- as well as go through the core things you need to understand about crypto and what to look for in a secure application.

• Password storage
  • Pitfalls
  • Doing it right
• Crypto crash course
  • Stream ciphers
  • Block ciphers
  • Asymmetrical ciphers
  • Hashes
  • MACs

Week 10

This week will focus on various common crypto bugs and discuss how to take advantage of them and how to prevent them.

• ECB failings
  • Block reordering
  • Block replacement/corruption
• Padding oracles
• Hashes versus MAC
• Stream cipher XOR

Week 11

Leading into the final week, we will cover several advanced exploitation techniques that will come in handy in secure real-world applications.

• WAF bypasses
• XSS via alternate encodings
  • Encoding sniffing
• External entity injection
• Advanced SQL injection

Week 12

In the final lesson, we will review all that has been learned, then run through several real-world scenarios from both an attacker and defender's perspective.

• Review of web vulnerabilities
• Review of crypto and vulnerabilities
• Scenarios for secure architecture design
• Scenarios for general web security

Schedule

Current plans are to begin classes the week of August 11th, then the subsequent 12 weeks from there. Each class will be one hour long and take place twice weekly (two identical classes), to accomodate different schedules.

I'm going to be taking a poll of students to see which of the time slots I propose will be best; as it stands, there will likely be one in the evening during the week (EST/GMT-5) and one earlier in the day on the weekend, to give coverage and flexibility to the majority of the world.

Price

The price is $1000 for early-bird sign-ups and $1500 for the remaining seats. This comes out to $125 a week ($83 for the early-birds) -- the best money you'll ever spend to expand your knowledge and further your career.

This price will double in subsequent runs of the course and seats are very limited. Being the first run, there will certainly be some bumps in the road, but I guarantee that everyone who participates will find it very valuable.

Sign up

You can sign up for the course at Eventbee, here. See you in class!

FAQ

Who are you and why are you doing this?

I'm Cody Brocious, a security consultant and reverse-engineer with nearly a decade of experience in the field. You can see my portfolio and read more about me on Wikipedia.

The reason I'm doing this is that I absolutely love the security industry, and having more people in the field makes it more exciting and makes the world a better place. Whether you stay in software development or become a security consultant, you will be making software safer and more secure for all of us.

How are the classes being run?

Each class is a live video stream where I give the class, diagram things out as necessary, and show relevant code and attacks. While that's going on, you'll be in an IRC channel where you can discuss the class and ask me questions in real time. The recorded class and IRC logs will be available after the fact for review.

In addition to this, you'll receive an outline of what the class covered and anything else that may help you along with your coursework.

What is the coursework? What about exams?

The majority of the coursework will be styled as a CTF (capture the flag). In essence, you will be breaking from day one and putting these attacks in practice. The exceptions are some of the crypto and the secure architecture/threat modeling portions of the course. These will be graded for your benefit but do not count towards your score.

Exams are largely practical as well, but will be more open-ended, as you will see in real-world security testing.

Can we work in groups?

Absolutely! I encourage you to form groups -- local study groups especially, if you're able -- and make use of the forums and IRC channel that will be provided. The one exception is on exams, as those are graded.

What do I get for completing the course?

You will receive a unique certificate upon successful completion of the course -- cryptographically signed, of course!

I have a question that isn't covered. How can I reach you?

Feel free to shoot me an email at [email protected] with any questions you may have. I look forward to speaking with you!

Sign up

In case you didn't already sign up above, you can do so at Eventbee, here.

In my opinion, there's nothing more interesting and challenging than the security field. When you come toe to toe with a particularly strong piece of software and you just have to break it, the only thing I can liken it to is a good game of Go. Every time you make a move, your opponent -- the designers and developers, by proxy -- will respond in kind. You know there's a way to win and it will take every part of your brain firing on all cylinders to find the weak link in the chain.

I live for the moment when I strike the right point and the whole system comes tumbling down. You will too.

Preamble

The goal of this blog post is not to be comprehensive; in fact, the opposite is true. My goal is to teach you enough about security -- specifically software security -- that you can go forward and learn the other parts on your own. To ease in that learning, I've sprinkled links to resources throughout the post; Google is also very much your friend here, as there are a million resources out there for most of these topics.

Once you read the General section, you can jump to any of the others (including the other blog posts, as they come out) as you see fit as they're written independently.

This post is focusing on web security. Posts on native security and crypto will be coming soon.

General

Prerequisites

It's rather difficult to come up with a list of prereqs for security, simply due to the breadth of the field. However, the following are the must-haves:

• Know how to program in one or more languages at a fair degree of competency (no one would expect you to edit a novel if you couldn't write the language yourself). If native security is your interest, at least one of these languages must be low-level; C is best.
• Understand what a computer does and how it does it. You don't need to be able to put together a CPU with tin cans and string, but you should be able to explain:
  • (Web) How HTML is parsed and how JS interacts with the page.
  • (Web) How HTTP works.
    • In fact, write a proxy. You'll end up doing a lot of that. (This is actually important enough that I'll probably write a blog post about this one day.)
  • (Native) How pointers work, how the stack is laid out, what the heap is, and (for bonus points) how syscalls work.

Where needed, I'll talk about more specific prerequisites.

Mindset

Before I can continue, I have to touch on the mindset of a breaker. Your goal is not to preserve user interactions or the intended flow of data through a program. Rather, your goal is to answer one simple question: Under what circumstances does this not do what it's intended to do?

Perhaps the best example of this is the cross-site scripting attack that's nearly everpresent in web apps; an attacker is able to output content to the page without proper filtering, allowing her to insert arbitrary HTML content and run scripts in the context of the page. The normal flow is preserved -- the data makes it from the user to the page -- but because that data contains HTML, the page is completely compromised.

The difference between intended and real behavior is what you're looking for in every case, whether that's a standard bug as described in the next sections, or a logic flaw unique to the problem domain you're testing.

Web Security

Must-have Tools

Below is a list of tools that you should have in your arsenal. Some of them are categories with more than one tool -- unless explicitly mentioned, they're roughly interchangable.

• HTTP(S) proxy -- This you will use constantly, as it will allow you to analyze and modify data in-flight
  • Burp Proxy -- Unless you have good reason not to, you should use this. It's the industry standard and by far the shallowest learning curve.
  • mitmproxy
  • Charles Proxy (UI is terrible -- only use it for AMF)
• DirBuster -- Useful for finding 'hidden' files/directories
• PadBuster -- Useful for exploiting padding overflow vulnerabilities
• Python or Ruby -- For general automation of tasks

Cross-Site Scripting (XSS)

XSS vulnerabilities are among the most common you'll see in web applications. The concept is simple: data from an attacker is put into a page without proper filtering, allowing the attacker to execute code in the context of the page.

Reflected XSS is when data from an attacker (e.g. passed in the query string) is directly output on the page. This is the most common form and is frequently used in conjunction with CSRF attacks (see next section). They are protected against by default in many modern web frameworks.

Stored XSS is when data from an attacker is stored -- generally in the database -- and then output without filtering at a later point in time. These are less common than Reflected XSS vulnerabilities but have a higher impact normally, due to the ease with which they can be used to target other users. Like Reflected XSS, these are protected against by default in many modern web frameworks.

DOM-based XSS is when data is inserted by JavaScript on the browser side without filtering. These are fairly uncommon but are not protected against by most web frameworks; they are becoming more common relative to the other forms of XSS vulnerabilities due to the protections afforded those.

In all cases, they are protected against by filtering user data before output, but it's important to encode for the right case. For example, HTML encoding won't serve to protect anything if the data is being output inside of a script tag; in such cases, JS string output encoding is needed.

• OWASP
• Wikipedia

Cross-Site Request Forgery (CSRF)

CSRF vulnerabilities are simple but highly effective and common. The basic idea is that an attacker points the victim (automatically with a redirect, or manually with a simple link e.g. in an email) to a page on the target website. The link to that page contains request data to perform an action, e.g. make a bank transaction. To the server, this looks just like a legitimate request and it's performed as if the victim had done it themselves.

Protection against CSRF takes the form of random tokens that are put into the form bodies of pages and then submitted with each request; the server checks the token and ensures it's a match for the user's current random token in the session and rejects requests that don't match. Most modern web frameworks have built-in CSRF protection but it remains a very common vulnerability.

• OWASP
• Wikipedia

SQL Injection

SQL injection is, at this point, one of the most well-known and prevalent vulnerabilities present in web applications today. The premise is that data from an attacker will end up being put into a SQL query without proper escaping. This leads to the attacker being able to break out of a string (most commonly) and add their own code to the query.

Depending on the code and the database configuration, this can range from bad (blind injection allowing slow retrieval of data) to super critical (arbitrary code execution, file access, data destruction, etc). Most modern frameworks are protected from this due to their use of an ORM; everything else should use parameterized queries where possible. When a raw query with attacker data mixed in is the only route, proper escaping must be used.

• OWASP
• Wikipedia

Shell Injection

Shell injection is fairly uncommon but almost always critical when it happens. When user data is fed into a shell command without filtering, it's possible -- through the use of backticks, semicolons, ampersands, etc -- to execute other commands at the same time.

Code calling out to a shell command using user data should always prefer execution methods where an array of arguments is provided (this is naturally immune), and use the appropriate shell escaping functions when raw command strings are built.

• Wikipedia

Directory Traversal

The most common forms of directory traversal are those where user data is directly used to construct a path to a file on the system. Without proper filtering in such cases, it's possible to insert a reference to the ".." directory entry, to walk up the directory tree. This can allow arbitrary reading/writing/deletion of files and is very frequently a critical vulnerability.

• Wikipedia

Insufficient Authorization

Insufficient authorization refers to cases where access controls are not put on certain pieces of functionality or data. A good example is a properly access-controlled administration console which has links to admin-only functions that do not have proper controls.

This is often seen in conjunction with forced browsing, in the case of improper controls on data.

• OWASP

Forced Browsing

Forced browsing -- also known as direct object reference -- is a class of vulnerabilities where an implementation detail is exposed to users in a modifiable way. Most commonly, this takes the form of an easily modifiable id parameter in requests, allowing an attacker to simply enumerate all possible identifiers to access/modify data.

• OWASP

Others

The topics above are a great starting place and they're things that I see constantly in testing real-world applications. However, the list is less than comprehensive, so here's a list of a bunch of other topics that you should read up on:

• XML External Entity Injection (XXE)
• Session Fixation
• Unchecked Redirects

Practice

I've recently been pointing everyone with an interest in websec to Natas. That wargame will let you use a good number of the exploitation techniques mentioned in this article, and some more advanced techniques that I didn't mention here. It also happens to be a whole lot of fun.

Other good resources include:

• Stripe CTF 2.0
• OWASP's WebGoat and Vicnum
• Maven's Web Security Dojo
• Peruggia

Going Further

Done practicing and want to dig your teeth into something real? Well, many companies are now running bug bounty programs where you can not only legally test their software, but get paid for the bugs you find. You can find a list of such programs here.

Happy hacking,
- Cody Brocious (Daeken)

I've just released the first version of my new blog engine -- powering this site! -- for public consumption. It's a super simple Python script, allowing for a huge amount of customization without so much as touching the actual blog engine.

This was built in response to Posterous' announcement to shut down, which I had been using for this blog previously.

How it works

At its heart is 92 lines of Python code which reads in entries from your blog directory, splits them into index pages, and runs everything through Mako templates that you provide.

This all enables a lot of flexibility and power, despite that it can fit on a single sheet of paper.

Example

You can see this blog on Github here: daeken/benjen

Next Steps

I'm hoping to package this nicely as a git post-receive hook, so that you can just push your blog to a repository and have it automatically rebuilt on the server. (Update: This is now done and documented in the README.)

Update #2: Benjen v1.1 is out with RSS support.
Update #3: Benjen v1.1.1 is out with some additional magic to support proper ordering of posts within a given day.
Update #4: Benjen v1.2 is out, switching to Markdown metadata for title/date, simplifying the code and making it more extensible for the future.

If anyone has other ideas, shoot me an email and let me know: [email protected]

Happy hacking,
- Cody Brocious (Daeken)

So, I've been quiet for long enough and it's time to discuss my plan. I've long said that we need a revolution, but that I didn't know the form in which it would come; I know that now. This is Distributed Balance.

Background

Despite their major flaws, we've seen the edges of the revolution for years -- forces pushing us to transparency: Wikileaks, Anonymous, etc. But the inherent problem is that we have a tiny portion of society helping out with these things; only a tiny portion has the skills to gain access to confidential documents or works in roles where that sort of access is possible. At the same time, we're in a position where we have so much data that it's impossible to catalogue and index it all.

In addition, centralized organizations such as Wikileaks are an inherent bottleneck when it comes to document releases, making it difficult for information to propagate effectively. This does, however, have the benefit of allowing them to redact names and the like from documents; whether this is desirable/acceptable to you may vary. Aside from that, it's very easy to strangle such an organization -- the US government has done so very effectively by cutting off their donations. This is not an acceptable risk.

What's Next

I'm designing a next-generation platform for distributing, indexing, and tagging large data dumps. Because the nature of such data may be objectionable to many, the platform is being designed with the assumption that it will be under constant attack legally, technologically, socially, and economically; it must defend against all of these points.

To this end, I'm going to discuss each of the design decisions and their purpose separately.

Federated

The system is designed to be inherently federated. By this, I mean that there will never be a central system containing data, receiving leaks, or hosting content. Rather, anyone will be able to set up a system to connect to the network, anyone will be able to add or tag documents, and anyone can publicly host the content.

This solves a few problems at once:

• No centralized choke point for leaks. Since anyone can push content into the system, it makes it significantly harder to track who is leaking what.
• The cost of distributing the content is spread out over a large number of hosts, rather than a single organization; this means that even if donations were sought out, it'd be far harder to shut down all of those payment endpoints. That said, because of the distributed nature, it's unlikely that any one host will end up with costs that are too high.
• It becomes far easier for innovative thinkers to build new interfaces to data.

Web of Trust

Because of the federated nature of the system, some trust protocol needs to exist; without it, anyone could poison the well by distributing illegal and off-topic content. As such, the design calls for each system to be linked to others and given trust ratings. The exact meaning of these trust ratings is still up in the air, but the concept is straightforward:

• Trust is ranked for each peer
  • How much you trust what they're adding
  • How much you trust what they're deleting
  • How much you trust what they're tagging/annotating
• Trust is transitive, e.g.:
  • There are three peers, A B C, with A connected to B, B connected to C
  • Peer A trusts peer B 50%
  • Peer B trusts peer C 75%
  • Because of the transitive trust, this means that A trusts C 37.5% (50% of 75%)

Details on this are still very much in the air.

Volunteer Mobilization

As mentioned earlier, part of the goal is to get volunteers involved. Right now there are a lot of people willing to sign petitions and all that, but what if we took that energy and got people actually organizing data?

In the first incarnation, volunteers will simply go to a node and receive a random document. They'll read through it and tag it appropriately, to the best of their abilities. One thought is that a short questionnaire might be the best way to go, with the tags being derived from those answers; the questionnaire would simply be written ahead of time by the leak uploaders, to make it situationally appropriate.

Getting volunteers to share documents and rope others into helping catagorize documents would be a big, big win for the platform; this is something that really hasn't been seen before. The people are there, they just need something to do, whether for 5 minutes or a week.

Search Engine

Journalists in particular have expressed the difficulties they have with dealing with the massive troves of information released by the likes of Wikileaks. As Google can tell you, organizing data into a form that people can drill down into to find what they want is very, very important. As such, everything in the system will be full-text searchable, as well as being able to filter by tags and things like that.

The technology for this is fairly straightforward, especially when you're talking about searching individual leak troves; there's a lot of data for humans, but not for computers.

Global Changelogs

To keep everything in check, we really need a system by which we can see all the changes across the system, at least for a few hops on the web of trust. This may not happen for v1, but this will be necessary as things scale up. Something akin to Wikipedia's vandalism bots would not go amiss here as well.

Problems

Below are the problems I see at the moment:

• How do we keep one node from becoming the canonical reference for the network? This will drive up costs for that node, make them a large target, and add a single point of failure for trust.
• How do we stop things like music, movies, and pornography from being stored on the network? The purpose is not general file-sharing, but specifically document storage and indexing.
• How do nodes find each other? One idea that has been bounced around is using IRC to match up nodes.
• How do we stop rogue nodes from flooding the network? One way is to use trust ratings to determine how big a change a given node can make in a certain period of time.

"Competition"

Services like Freenet enable people to publish and share documents at the moment. However, due to the nature of the system: documents are immutable, searching isn't possible without pulling down the contents of the archive, and annotations have to be external.

The same tradeoffs exist when, say, publishing a torrent full of leaks. A federated system like this is complex, but it allows for these fundamental issues to be dealt with.

Getting Involved

Simply put, things are very early stage. If you want to get involved, join #distributedbalance on irc.freenode.net. Design is underway, and bodies are needed.

There's also a Github repo, primarily for tracking issues and designing in the wiki.

Happy hacking,
- Cody Brocious (Daeken)

It's a new year, so it's time for a quick wrapup post.

Last Year

• Obviously the big thing was my Black Hat USA talk on breaking hotel locks. The attention it's received has been insane; I never expected anyone outside the lock industry to care about it, but it's been featured in every major publication and even on national TV. Quite an experience.
• I spent February-December working for Mozilla on the Boot2Gecko/Firefox OS project. Lots of interesting experiences and a great team.
• In November I built QtzWeb, the first Quartz Composer implementation not by Apple, compiling it to JS WebGL. I released the first demo using it at Kindergarden, and dropped the source on Github recently.

This Year

• As always, I have something new and interesting brewing, which I'll be showing off in the next few months.
• I have an upcoming series of posts on getting into security, of which you can read a preview.
• I started work at Accuvant LABS, where I'm a Senior Security Consultant.
• I'm going to be splitting my time between the middle of nowhere in Connecticut, and Barcelona, starting in April.
• QtzWeb -- the previously mentioned project -- is getting a web-based editor to cut Quartz Composer out of the picture entirely. This has a lot of potential for interactive 3d content on the web.

I'll be posting some more in-depth blog posts soon, but in the meantime have a happy 2013, and thanks to everyone for their support over the last year!

Happy Hacking,
- Cody Brocious (Daeken)