Most dynamic web applications store a unique identifier about the visitor who is logged into them. Webpages are stateless. So each time the dynamic page loads it needs to know the web session this new request is i nrefrence to. Erfo session state.
Attackers like stealing session state, which makes the URL query sub optimal. Cookies aren’t great either but are considered more secure by many for tracking session state.
But it occurs to me there is an awkward but interesting third way.
Dynamic apps served up by a web server recieve data from the query string when awebserver fullfills a browser’s get request. But they also recieve data from post requests which require no exposure of session in the URL or in query strings. Post data is protected by the inherent SSL connection between the web browser and the server.
Post requests require the browser to be submitting something. However in the modern age of CSS we can theme buttons as links and continously move from page to page within a dynamic set of webpages preserving session state, without cookies or having the URL intercepted.
Also such session data immediately becomes lost when you leave the application for another webpage. Which may be inconvenient if you want cookies to autologin someone every time they visit a page; but also prevents a dynamic page from tracking beyond it’s borders.
My questions:
Does anyone do this now? (Im kinda ignorant of most modern web programming after all).
Does this breakdown in any way that isn’t obvious to me? It’s exceedingly awkward but completely plausible in my brain right now.
First off, I love weird, non-standard ways of tackling problems, so I love this.
You’re asking if someone uses POST requests for all site navigation? Not that I’ve seen. Having all links be little tiny forms would be unique. I am all for unique.
On the dev side… it’d need to do something like have a continuous payload it’s putting in these little forms to carry around the data. Unless I’m totally misunderstanding.
I haven’t thought about it at this level. I figure they would both be equally secure, ne? If it is over HTTPS, I’m not worried about the strings in the URL.
Your understanding is correct. And yeah you’d have to keep posting some unique identifier back into the dynamic page every time, which would require the session key be stored in the page everytime it’s generated too.
Yeah. My brain is on a javascript-less train right now.
In theory yes. In practice a lot of people have figured out innovative ways to go after the URL. Also users tend to copy and paste URLs, which leaves session unique identifiers lying around in clipboards and wherever they pasted them. Lots of security documents ive been reading on CGI scripting advise against them.
I don’t know if I want to build this; but it occured to me while digging into CGI scripting that it could be done, and it’s kinda interesting to my brain.
See, I ask because, what do we use it for? Like, I get it, that’s pretty clever. But how do I get it started, and for what?
We can’t really make it like a, um, temporary device login. Because we still have to auth somehow.
It does make permadeath gaming a fun idea! CYOA, click on choices, server is tracking everything. Close the window and game session is gone! There is likely no money in such an endeavour, so I can see why alternatives picked up.
Edit: how many web games let you put your initials in at the end?! It feels very arcade.
You’d have to have an initial static page or a dynamic page loaded by a vanilla HTTP get request as a trampoline into such a system.
Load landing page with HTTP get. No session id is needed yet, because user isn’t logged in. It has the username and password fields.
Submit username and password on landing page with a HTTP post request. Like all dynamic apps have to do today.
All further calls HTTP post using the above outlined shenanigans.
Its in theory applicable to any such dynamic web app; but since (maybe) all web infrastructure isn’t built around this concept their would have to be a whole lot of wheel reinvention.
It pretty much kills the need for cookie tracking, so there was never ever really much chance of it to be a money making endeavor.
It seems like it could break back/forward button functionality in the browser or atleast make it fragile. (Lots of popups from firefox if you would like to resubmit the form).
Though a lot of web apps these days don’t respect back/forward so thats not the worst down side.
