Comment by XorNot
7 years ago
This still seems like really bad idea when the POST request is right there.
Serve a page with a button saying "are you sure"?
7 years ago
This still seems like really bad idea when the POST request is right there.
Serve a page with a button saying "are you sure"?
A reboot of the machine isn't the end of the world and far less risky than a garage door randomly opening. It probably needed it anyway as they tend to degrade over time. This is a very specific usecase. If it becomes an issue, I can always push out an update of the software that switches things to POST (thanks to using the golang library, overseer).
It still seems a bit odd to do it this way when it's so easy to do it right.
I hope the hostnames / IP addresses aren't predictable, because all it would take to cause trouble is to send an HTML email containing something like <img src="http://192.168.0.1/reboot"> to your staff and then you'd trigger a bunch of reboots whenever anybody opened their email. Or just send a link to a page that does the same thing. Or text a link to them and wait for iMessage or whatever to preload the page to get the preview. There's so many different ways to trigger an automatic GET precisely because GET is defined to be safe.
I feel like the 'do it right' comment is a bit speculative or entitled. It does create a usability barrier that I was trying to avoid. Even the extra button click is a pain in the ass when you're rebooting dozens of machines (sometimes daily).
Your second paragraph is spot on. Very good point and kind of why I posted here in the first place. Two minds are always better than one. I forgot about the image attack. I've seen this used in the past to 'win' contests by sending in votes over GET.
Luckily my IP's are pretty hard to guess, not a standard range, but you're right... that is a totally valid 'attack' vector. I'll make the change asap.
1 reply →
Do you really like having to confirm every action? For interfaces that you use all the time, it's nice to be able to eliminate extra steps.
If you're using it programatically (e.g., a script that's calling curl), it's absolutely no trouble to use POST.
If you're using it from a browser, you can write it with a confirmation page for simple browsers, but also use just a little javascript in normal browsers to convert the GET to a POST and skip the confirmation page.
Also, if you have a confirmation page on GET, then it must be submitting to a POST endpoint that you could still call directly.
Every action? No. Rebooting a machine, however?