Common API Security Pitfalls - Philippe De Ryck
Вставка
- Опубліковано 25 лют 2020
- I always list this talk as an option, as it remains very popular at many conferences. It also draws a full room each time. The shift towards an API landscape indicates a significant evolution in the way we build applications. The rise of JavaScript and mobile applications have sparked an explosion of easily-accessible REST APIs. But how do you protect access to your API? Which security aspects are no longer relevant? Which security features are an absolutely must-have, and which additional security measures do you need to take into account?
These are hard questions, as evidenced by the deployment of numerous insecure APIs. Attend this session to find out about common API security pitfalls, that often result in compromised user accounts and unauthorized access to your data. We expose the problem that lies at the root of each of these pitfalls, and offer actionable advice to address these security problems. After this session, you will know how to assess the security of your APIs, and the best practices to improve them towards the future.
Check out more of our talks, courses, and conferences in the following links:
ndcconferences.com/
ndc-london.com/ - Наука та технологія
This expanded my considerations for API architecture quite a bit. Thank you Philippe, you rock! 🎊🏆
Good to see the Javascript world finally rediscovered public-private key infrastructure.
Great talk. A small quibble: At 18:20, we know we can trust the token because it’s defined on line 1. There’s no point to verifying it at run time, when you can verify it at design time. The quiz might be more effective if it weren’t clear that the token doesn’t come from a client. I know I’m taking the code too literally, but if you show someone code and ask them to find a security problem (or any other kind or problem) they should be reading with a very literal mind set.
It's when external consultants tell your management "Oh, yeah, easy to convert that to a REST API" and you spend the next 2 years having to explain to your manager that "yes, it's easy to make a REST API, but not so easy to make sure that that REST API doesn't dump our customers' data all over the internet"
at 22:36, is the proposed "JTI" solution optimized? Because fetching invalid tokens in a ( huge ) database, might be long ?
31:53 How is providing an additional key in any way a valid behaviour here? The party verifying the token will only need a x509 certificate. Only if the "with a key" part is not contributing extra information but was meant to explain that the certificate intrinsically contains a/the public key it has some value. It probably should be changed to "..certificate which contains the public key"
It’s one of my biggest gripes with modern software learning material: pretending security doesn’t exist. It’s always a side note like “that’s a topic for another discussion”
I think maybe because security is not a proven thing, and large relatively secure companies are hacked all the time. It makes it more similar I think to giving financial advice. Usually people hesitate, and if they do they provide a disclaimer.
How can an indie application developer possibly learn security without becoming an infosec expert?
some of the best world's best news companies, such as; "the economist" suffer from that overexposing the contet! they send it to the client to block it afterwards... instead of sending just a preview! I already sent them a vulnerability report, but they don't really care apparently
because it's just content -- the number of people doing this is likely small, and the type of people doing it likely won't pay anyway.
They have reasons for that actually.
a) The people who circumvent this paywall are not likely to pay anyway. In fact, the hassle of circumventing this every time makes it more likely they'll eventually just subscribe. If you simply ban them from any access, they won't even ever come back.
b) To prevent those same people from setting up other ways to share it illegally. Now, if you search for how to get passed the paywall, you'll find articles explaining the steps you need to take. What you don't find is illegal sites simply rehosting the same content, but that's what people would turn to otherwise.
I think it's bad advice to encourage systems to CHECK permissions. This opens a vulnerability to a confused deputy attack at the least. Better yet to make it impossible to make it unauthorized requests.
``` 12 hours running token``` seriously? I think it is not `tocken` problem.
Some client requires it because there are offline situations. But the situation might be sure to store the token securely. If we only focuses on Web Security, your reaction is.