Hacker News new | past | comments | ask | show | jobs | submit login
Stanford CS253: Web Security (stanford.edu)
153 points by feross on March 24, 2020 | hide | past | favorite | 19 comments



I want to be careful throwing shade because I apparently know some people involved in this, and they are smarter than me, but this is pretty basic. Take a whack at the 2019 final exam for a flavor of where they're at.

The CORS content is solid. But the vulnerabilities themselves are dated. As a threshold concern, a 2020 web security class needs to be teaching about SSRF, the most important current web bug class. OAuth flows would be another thing I'd hope to see covered.

There's always going to be new stuff that can't be covered; I understand how these curricula work†, and don't expect HTTP Request Smuggling or DNS fingerprinting on the final. But system("cat ${input}")?

The network security course taught at major CS research universities was written at one place like 10 years ago and shared and handed down from semester to semester; I assume something similar happens here.

PS

3 hours is a bananas amount of time to get for this exam. We're speedrunning it on Slack and the median is closer to 15 minutes (albeit without writing careful answers). If this were a commuter school with students who don't come in knowing how to code, sure; but this is Stanford CS!


Sadly, this is the case at many major CS research universities. I'm working on my Master's in Cybersecurity at one of these universities and most of the papers we read are something the professor co-authored in '08 or '09. Network security, and most security classes in general, are being taught 15 year old material.

> † The network security course taught at major CS research universities was written at one place like 10 years ago and shared and handed down from semester to semester; I assume something similar happens here.

This couldn't ring more true, in my experience. Whats worse is that each year the material is lightly modified so that you're also dealing with 10 years of revisions creating an incoherent mess.


I’m speculating here but perhaps one factor that adds to this situation is that people who are good at the stuff taught in this course, and have skills that are up to date, will earn lots more working for a FAANG than in academia.


What do you make of this one? — https://portswigger.net/web-security/all-materials


If you are interested in learning web app security but can't get into Stanford, consider reading this book: https://www.amazon.com/Web-Application-Security-Exploitation...

Covers just about everything a software engineer (or web developer) needs to learn in order to get into security.


The Web Application Hacker's Handbook is also practically a must-read for those in the field.

https://www.amzn.com/B005LVQA9S/


+1 for WAHH! It is quite good in that it covers everything and is very readable for a book on subject as this.


> If you are interested in learning web app security but can't get into Stanford...

there's slides, video, and linked readings for all the sessions in this class, though.


The gold standard for this stuff is The Web App Hacker's Handbook.


Can someone explain me one thing?

>When accepting untrusted input from the user, we should escape it before it is added to thedatabase so that we can later use it without worrying about escaping.

I tend to believe that despite very popular saying `escape everything!!!` it isn't so practical

Let's say I have ASP.NET Core WebAPI which is using EF Core + Vuejs on frontend

I'm accepting user input which is being binded to model (class) without escaping and saving it straight to db (ofcs after basic validation like strings length and business logic)

I'm using parametrized queries, so I don't have to worry about about SQLi, then I'm returning that data as json and the client (frontend, vuejs) escapes it and renders as text.

If I escaped that data before e.g `Germany / Berlin / 15B` after escape it'd be `Germany \/ Berlin \/ 15B`

then it'd less practical to use thing kind of data because whenever you'd want to use it, then you'd have to take into account that there may be some "weird" characters.

So how it is? I tend to believe that sql parameters and escaping on client side should be done instead of escaping at the beginning

Also I tend to believe that SQLi should be non-existent problem nowadays(and before tbh) because it's always possible to compare ASTs. SQLi will always? modify AST, yea?


Hey Feross, took this class in the fall and loved it! Highly recommended for anyone who wants to get the lay of the land in web security.


Wasn't this just posted a few days ago? I went through some materials and it's top quality.


Looks like it was posted under "Stanford CS243: Web Security": https://news.ycombinator.com/item?id=22642220


Judging by points, this is a clear dupe. But there wasn't much discussion, so maybe we'll leave this up for a while to see if a meaningful discussion arises.

In a way, course pages aren't a great basis for an HN thread. They're a list of more specific topics, and lists don't work so well on HN, which itself is already a list. I think you can see this already in the comments here as well as in the previous thread: they tend to be generic (e.g. security in general) rather than diving into specifics where the real juice would be.

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...


Is this an ongoing course or anyone can join and read the material at own pace?


Real web security is fighting back against browsers as the OS and executing all arbitrary JS code like grandma opening every email attachment she gets.


Not gonna happen, the real web is all about running arbitrary JS code these days.


Thank you for your input everyone, a lot of great resources a student like myself appreciate.


Ugh... any course that references Forbes clickbait articles is a no-go for me. Thanks, but no.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: