[HN Gopher] A heck of a wild bug chase
___________________________________________________________________
A heck of a wild bug chase
Author : togakangaroo
Score : 32 points
Date : 2024-08-08 17:17 UTC (1 days ago)
(HTM) web link (georgemauer.net)
(TXT) w3m dump (georgemauer.net)
| jof wrote:
| It seems to me like the underlying issue was ignoring HTTP
| semantics and making a state-changing link like a logout link a
| plain <a> (HTTP GET) and not something like a form submission
| (HTTP POST).
|
| Having intuition for the foundational layers of our tools saves
| so much time and future headaches.
| graypegg wrote:
| To be fair, <a> tags can't send out non-GET requests. Which
| yes, can be interpreted as "logout controls should be buttons
| in forms, not links", but I would really like native htmx-like
| attributes for intractable html elements.
| Ethee wrote:
| Genuine question: How do you believe one should learn these
| semantics? This is more something I've been pondering myself
| recently, because I agree with you that the foundational
| knowledge for our work in any tech stack is usually the most
| important for understanding higher abstractions. But with so
| much to know it feels impossible to 'know it all' so to speak
| especially if you wear more than one specialized hat. Then
| beyond that even if you're only trying to learn just the
| foundations how do you know what those foundations are if
| you're not already inundated in that stack?
|
| This is mostly just my personal ramblings, but I'd be curious
| other peoples viewpoints on this.
| pixl97 wrote:
| While it may not be quite the same answer you're looking for,
| I'd suggest the OWASP, and at least their top 10 for sure.
| Learning about SSRF may not have stopped this behavior (it's
| coming from the authenticated browser), but if you're doing
| CSRF checks you won't get logged out by random links on other
| peoples sites, and that whatever logged you out was a
| legitimate action.
| codetrotter wrote:
| I remember many years ago when I used to read print magazines
| about programming and web development.
|
| One of those magazines told a story about a web site that had
| lost a lot of data. What had happened? Well, somehow they had
| this page that
|
| 1. Required no authentication at all, and
|
| 2. Was using links like <a
| href="/path/to/file?action=delete>Delete file</a>
|
| And so the Google web crawler had come across this page and
| happily visited each and every one of those links.
|
| That's when I learned about the importance of using forms
| with POST requests for certain actions instead of using links
| that send GET requests.
|
| And then some years later someone told me about this thing
| called HATEOAS and about RESTful APIs and that actually there
| are different HTTP verbs you can use other than just GET and
| POST. Like for example DELETE /path/to/file
|
| As for your question about how someone is supposed to learn
| that these days?
|
| Ideally whatever web development tutorials or courses or
| books they are using would at some point tell them about the
| different HTTP verbs that exists, and of how and when to use
| each of them, and crucially to tell them about bad
| consequences of using GET for anything that has side-effects
| like logging out a session or deleting a file.
| recursivedoubts wrote:
| This is a very good example where the HTML extensions that alex
| proposed here:
|
| https://www.youtube.com/watch?v=inRB6ull5WQ
|
| (TLDW: allow buttons to make HTTP requests; allow buttons &
| forms to issue PUT, PATCH & DELETE; allow buttons, forms &
| links to target elements in the DOM by id instead of only
| iframes)
|
| would improve the web platform. You could have a stand-alone
| logout button that issues a DELETE to /session or whatever.
| Nice and clean.
| togakangaroo wrote:
| Author of the post here,
|
| There was no form submission, I'm not sure where you got that.
| There was also no POST. Though yes, I agree that in the core
| HTTP semantic, you wouldn't want to change state on a GET and
| that should _include_ not calling `Set-Cookie`. And yet the
| reality is that that nearly every application - and many
| popular libraries like auth0 - do in fact set and clear cookies
| on `GET`.
|
| The issue here was that the `Link` component in NextJs
|
| - does preloading by default (which is a bad idea exactly for
| the above reason of reality being different from theory)
|
| - _doesn 't_ do preloading by default when running on the dev
| server (so you don't see the error until its deployed)
|
| - _because_ it does preloading directly in javascript, it can
| 't possibly follow the HTTP semantic of not actually applying
| cookies until _later_ when the cached route is used
|
| Everything else was the wild goose chase bits.
|
| Also I asked claude to criticize the article as a web forum
| might before publishing, and this is definitely the tone it
| gave :D
|
| Oh, also, I'm pretty sure I got the part wrong where i was
| talking about the preload attribute in HTML, but so far no
| one's noticed. I should correct that.
| thedanbob wrote:
| > There was no form submission, I'm not sure where you got
| that. There was also no POST.
|
| OP was saying the logout function _should have_ been behind a
| form submission / POST.
| andrewfromx wrote:
| I always do <a href="#" id="logout">logout</a> so there is no url
| to accidentally GET call anyways.
| Etheryte wrote:
| This is the worst of both worlds, it doesn't conform to the
| spec and it has incorrect semantics. See HTMHell [0] for a
| brief discussion on the topic, albeit with a slightly different
| example.
|
| [0] https://www.htmhell.dev/8-anchor-tag-used-as-button/
| andrewfromx wrote:
| ok fine <a href="/" id="logout">logout</a> but at least / is
| safe to GET
___________________________________________________________________
(page generated 2024-08-09 23:00 UTC)