Don't like this style? Click here to change it! blue.css

Welcome .... Click here to logout


It's been a true pleasure to work with you all this semester.

May you have grown in a way that is meaningful to you over the coming decades.

Here are some of my parting bits of life advice:

Alright I also like to take a look back at all that you learned or were exposed to during this semester:

Well that's a lot. Obviously you haven't mastered all of that, and honestly the list is probably incomplete in terms of the many skills you had to figure out in your various projects along the way.

But for 30ish hours of lecture time that's a pretty decent ROI IMHO.

A last concept set

Request Smuggling

I've been wanting to teach you cache poisoning and HTTP desync (request smuggling).

I wasn't quite good enough to write my own problem for those so I (and JD) have given you a send off:

DEFCON uploooad-it: You can find write-ups out there too, but maybe try it first without them.

DEFCON is the holy grail of CTF competency so I think it would be a real win if you're able to crack it.

Now here is what the two concepts have in common:

The idea is to take advantage of a particular weakness in a particular library to essentially put a break between two requests that gets honored by one program but not the other.

huh? You send a request to a proxy (a load-balancer) and it reads one of your headers to know where the end of your data lives. The rest of the data is sent along to another gateway (gunicorn then flask) which processes the data in a different way. This actually let's you set headers for the request that comes after you...

Here just look at this:

CRLF injection

There's actually another variation on this theme called: CRLF injection (Carriage Return Line Feed) where if you can control (with a parameter) some contents in a server rendered page then you can induce a fake end to the HTTP data and put in your own fake start to a new HTTP request but this time it will seem like it's from the localhost.

Cache Deception

The third variation on that idea is cache poisoning which is best

Here the idea is that whenever a server caches a website it does a pretty weak job of catching all possible changes to that site. So it uses the /path/you/request and maybe the params to cache your files.

So if you can find any header/param that will be included in the resulting page you can poison the cache for other people with something you've injected. Here's a diagram and some screenshots to quickly get the idea across:

DNS Cache Poisoning

Yet another variation on this theme:

Here it is in pictures (from CloudFlare):

A parting gift from me

So I'm interested in you continuing to grow by participating in CTFs, Bug Bounty programs, and pentesting for real clients (with their permission):

With that in mind here is a flow chart of my CTF thinking in the various topics. It's a little rough but I'll keep refining it at this location:

CTF Flowcharts and Links

A victory lap!

Now let's look at some student made CTF problems from this class and see how quickly you can knock them out:




Noah 2:

Noah 3:

If you'd like to help build problems for our next Blue Hens UDCTF in the spring hit me up!


As you progress through your career feel free to reach out if you got value out of this or if you've got feedback!