A bit unrelated, but I find funny most frameworks don't even have something to prevent CSRF. Most devs don't even know what CSRF are, and some know it only as "the stuff I need to disable because some ajax POST won't work otherwise".
In fact, every time somebody choose flask over Django, I ask what they are going to do about CSRF, only to get a blank stare. Same with manual PHP or using most nodejs web libs.
There are so many websites that are vulnerable to this, and it's something we know well, and have solutions for. Imagine what we don't know about. The internet is really made of swiss cheese.
Working with Django has completely spoiled me as a dev. Now, I really can't stand manually configuring a lot of the "normal" good-practices that Django gives you for free.
Now that you mention it, I can't think of any other concept I eventually researched and learned about just because of frameworks complaining (Spring framework in my case).
1. Not all servers serve web pages. As for how big percentage of Flask users thus don’t need CSRF is hard to guess
2. WTForms is not the only way to do CSRF tokens with Flask
My point is that it’s not plausible to infer with certainty that some large part of Flask users would not have CSRF tokens just because Flask has more downloads than Flask-WTF
Just anecdata but me (and my team back then) used Flask for years, I'm pretty sure zero of our apps even had a form for users to interact with. It used to be very popular for REST APIs.
Indeed, you can also create a Jinja macro to auto-insert the token into all of your forms too, here's a code example[0]. It's a 100% solved problem both on the Flask back-end and template side with an ability to opt out of it when you need to on the back-end such as when accepting webhooks from another service.
I haven't really thought about CSRF since building things that are purely static frontend + JS request based. How prevalent are these things in this space? Are they still a problem?
This issue was due to a change on how the default framework configuration was being set. The side effect was that if you didn't explicitly enable CSRF protection, it would default to being disabled. The issue was resolved/disclosed very quickly, and in a professional manor.
Professionalism, in my opinion, includes taking reasonable precautions to prevent the problem from happening.
If you are professional you know what kind of potential problems might happen and you know what are reasonable possible approaches to handle it.
If security of your piece of software relies on default values of some settings I would reasonably expect you to have automated tests to verify that these settings have correct values.
Next time you hire an electrician who causes damage to your house because he did not follow procedure to wire it correctly, will you be still calling him "professional" because he quickly removed the short?
Expectations of professionalism, software quality, process, and so on are all a matter of context. I'm not sure a FOSS web framework gets DQed for a quickly-rectified mistake. The expectations aren't that high and can't be that high.
I agree with you, but open source software is given as-is, in any context, if you see the headers and/or README files and/or LICENSE files, it says that there is no warranty given and considering that the whole (tech) world sustains itself on stealing the work of volounteers, I would reply that if a piece of software is not professional, then invest to make some professional work that works for you
> I agree with you, but open source software is given as-is, in any context,
But if you are calling somebody or something "professional" what you are saying is they act as if they were doing it in a certain way. If they don't follow the practices it does not matter if they are doing it for free.
It is like saying a kid is doing something professionally (even if he is not) and argumenting that it is because he isn't paid for it.
I think symfony developers are still good professionals, given the size of the project and the amount of contributors, having an error or not having a test case for something specific could be forgiven, I would reply that errors and bugs can slip in a codebase, I guess it's more important to create a test case to double check that a bug doesn't re-appear in the future after it has been fixed?
I mean I fail to understand what are you trying to say, someone stops being a professional as soon as it hasn't covered a test case?
Or are they kids just for having slipped a bug? Despite their work powers a lot of companies software (including the ones I work for)
I don't know if they are or are not professionals.
It is just my opinion that being nice and prompt about removing cause of the damage after they have caused damage through recklessly ignoring industry standards cannot be reason to call their entire set of actions around this particular issue as "professional".
It shows lack of experience to suggest having a gap in testing is somehow "recklessly ignoring industry standards". If you look at Symfony's test suite it's clear that they take testing extremely seriously and keep their tests up to date in a way that's far superior to my experience with "industry standard". If you look at the fix for this issue which is linked from the OP you'd see that the first thing they did is add a unit test to prevent this kind of issue from happening again.
If you consider that kind of behavior recklessly unprofessional I'd be amazed to see the kind of tests you write for your code.
If you are using an up to date version of Firefox, Edge or Chrome it defaults to Lax. The exceptions are Safari, IE and Safari for IOS. I don't think this is worth a 8.1 CVSS.
Unfortunately, most people don't understand the technical nuance between protective measure X and Y will fall for it. People do seem to get the concept of defense in depth through when explained through the castle analogy.
I took a job at a subcontracting about 9 years ago, where I was mostly doing Node.js work, but there were some projects using Symfony, and even after using it on/off for a month, I have to say I never really "got" it. I could tell there's something there that's fairly cool, but I never really was able to wrap my head around all the folders.
I've become a way better programmer since then, so I have thought about trying it out again, but nothing in my day job uses PHP anymore, and I've moved away from web since then.
I really enjoyed using Symfony for a lot of years.
The frameworks around before, Zend & CodeIgniter, were flawed in my opinion and Symfony was a breath of fresh air. More recently though, it feels like Laravel is doing a better job at letting people just get on with building a website.
Personally I think Symfony (and digging around its source) helped me become a far better software developer. It wasn't perfect, but it was awesome at the time. I built some really cool applications with it early on. Over ten years ago now!
No doubt about it though, some very talented people contributed to that project and I imagine they still do. Symfony was one of the lights in the dark if you ask me; PHP could be a very ugly thing at the time, but it proved that you could do great things with it by applying good practices and being diligent about reviewing and improving designs.
One of the things that blew me away (I was pretty green at the time) was when they made all of Symfony modular, and other frameworks began consuming their components. The portability of all of it was so impressing and inspiring to me back then.
Anyway, plenty of ways to criticize PHP and Symfony, but I think they did a stellar job. I built my career on that stuff. I haven't actually looked at it in quite a while, though.
To be fair, Zend and CodeIgniter had to juggle operating between PHP4/5 at the same time. The object model in PHP4 was mostly incomplete and just syntactic sugar. It also did some oddball things like flip-flop pass-by-value/reference.
That was quite popular a while back also. I tried to pick it up when I first got into web development and never really understood it (didn't really understand MVC at all) and started using CodeIgniter (which is also still going) instead which seemed more straight forward - although used it more like VC rather than MVC haha.
Sure, but this was the presence of a bug. In a web framework you can easily have a test that fails when CSRF vulnerabilities are present. It's not some zeroday that has just been published, CSRF has been known for a very long time now.
In fact, every time somebody choose flask over Django, I ask what they are going to do about CSRF, only to get a blank stare. Same with manual PHP or using most nodejs web libs.
There are so many websites that are vulnerable to this, and it's something we know well, and have solutions for. Imagine what we don't know about. The internet is really made of swiss cheese.