It is more about complete lack of authorisation, not about rolling your own. My example above would work 100% in that case.
No, proper authorisation do not fix that at all. The description of this issue already assumes that user has been authorised. It is more about not validating which data is possible to be fetched, like hashed password. No authorisation framework out there would secure you against such attack.
This has nothing about authorisation at all as well. TBH nothing except aware developer can protect you against this.
From this list, the only thing that isn’t automatically taken care of in combo of Plug.Session and comeonin is the point about brute forcing. Others, as I said, are covered pretty well, especially the point about JWT, as I do not like them at all and I think that PASETO is much better standard. The rest of these, again, is more about aware developer as no framework will make you safe against them.
But using this Authentication and Authorization libraries do not fit in what I was telling about not rolling your own solution. I am all in favor of them being used, but yes developers can use them wrongly.
As I said earlier - depends where we put line of “rolling your own”. Depending on the framework will make you more susceptible to point 1 in OWASP API7 and would make it harder to accustom solution to your needs, but would allow you to roll it faster. For me it is much better to have flexible solution crafted from lower level libraries than to fight with “one-fits-them-all(until-it-not)” solution.
There is certain logic behind not making default modules like that because it would be an attack vector. This is why a lot of php based frameworks have security issues. Much less the security flaws when several languages are allowed to run in the server stack. There are too many examples for this, but one that really runs amok is the e-mail filter manipulation that results in executing whatever you want in a new root shell window on the web server from filling out a php-mail form on a web site…
Well most third-party libraries that I see in Elixir are developed by people rolling their own system and open-sourcing them. So we have to be more specific to which kind of libraries you’d consider as acceptable.
For example, if one needs a simple auth-n system based on Cookies (Phoenix’s default session storage for sessions), rolling your own based on Plug.Conn.get_session/2 and Plug.Conn.put_session/3 seems reasonable. If not (and you exclude that as soon as you typed never in uppercase and bold letters), I’d appreciate a more detailed answer as to why not.
Due to the fact of using a web browser, which they were not originally designed to do nothing but display html pages and no user input, session cookies are the only logical choice.
I think a count instead of select queries for authentication seem safer. Binding parameters and escaping user input is other concerns I have…
I think the best way to do it is to write a separate admin program to do that.
But it wouldn’t be hosted at that location, because editing should have been done before the application was uploaded and executed. Its not a web site, nor a collection of script pages in a directory somewhere mounted as a publicly accessible url.
