Oh go fuck yourself, Apple
-
Have a production website that's been crashing randomly. IIS (or more specifically the App Pool for that site) goes down. Windows event logs hint at a stack overflow. Okay, so there's an infinite loop somewhere-- and if it gets triggered, it takes down the App Pool. If the app pool crashes more than x times per minute, IIS takes it offline until you manually turn it back on.
Check a DebugDiag onto the server, and I just caught the crash. Look at the stack trace, and yeah-- there's a weird case where an Item tries to load which tries to load the Category for the item which tries to load the Item which tries to load the Category for the item and so forth.
But this doesn't quite "feel" right. I specifically coded for that possibility. And the code is there. There shouldn't be an infinite loop. What's going on?
Look at the stack track again, it starts in SpecialSearch.aspx (redacted for reasons). It's a page that goes POST'd to with an item no, does some processing, then redirects to the correct item page with a filter. (Not my design, I take no blame for that).
But it's implemented as a ASP:Button with a PostBackUrl. For those not familiar with ASP.Net-- the entire page is wrapped around one FORM element that POST to itself. But you can have buttons that, when you click them, first change the target of the FORM so you can post to a different page. It isn't a widely used feature because it's dumb. But it's there.
Well, the only way to reach that page in the system is on a "select which filters you want" page. You click a checkbox, and some Javascript sets some POST parameters, and then clicks a HIDDEN button that posts to SpecialSearch.aspx.
After some investigating, I find that if you go straight to SpecialSearch.aspx with no POST parameters, the lack of an ItemNo specified causes an infinite loop. Too technical, beside the point. And it should have been handled already. Easy enough to do... "If no Item No. in the POST, then Response.END".
But I'm still puzzled. There's no way a user was clicking on the hidden button. It's hidden. And even if someone was playing around and took off display:none and clicked the button out of curiosity, it would have just lead to an error page. MOST LIKELY it's not a regular user.
What about a search engine? They love to follow links and forms. The problem is two things: 1) the page's on form points to the page itself, and 2) there are no hyperlinks. An ASP.Net button with PostBackURL set looks like this:
onclick=javascript:WebForm_DoPostBackWithOptions(new WebForm_PostBackOptions("ctl00$SpecialSearch$test", "", true, "", "http://THEURL/Specialsearch.aspx", false, false))That onclick kicks off some ASP.net logic which, in turn, populates the POST and does a postback, etc. SO there's nothing for a standard crawler to follow.
Now that I know what's causing the site to crash, I pull up the IIS logs and look at anyone who has visited that page. And what do you know, nearly every single one of them is iPhone or iPad or a different OS using Safari. Safari's (using WebKit) has a bunch of stupid link preload and predictive resource loading. They either parsed the URL out of the onclick attribute, or noticed that this page sometimes goes to SpecialSearch.aspx, without considering the POST values.
Which means that Apple's browsers are so aggressive and trying to pre-cache, they'll blindly follow any URL they recognize, without thinking "hmm, I usually send this with POST data, maybe I shouldn't just POST to the URL without data. durrrrr"
-
@lorne-kates said in Oh go fuck yourself, Apple:
Which means that Apple's browsers are so aggressive and trying to pre-cache, they'll blindly follow any URL they recognize, without thinking "hmm, I usually send this with POST data, maybe I shouldn't just POST to the URL without data. durrrrr"
Makes me want to hide a link to a 8gb file that can't be clicked and see if it can be used in a buffer overflow...
-
hmm, I usually send this with POST data, maybe I shouldn't just POST to the URL without data. durrrrr
I know nothing about web stuff, but isn't POST for requests that are explicitly not nilpotent?! As in, you shouldn't randomly POST stuff, ever?
-
@topspin said in Oh go fuck yourself, Apple:
hmm, I usually send this with POST data, maybe I shouldn't just POST to the URL without data. durrrrr
I know nothing about web stuff, but isn't POST for requests that are explicitly not nilpotent?! As in, you shouldn't randomly POST stuff, ever?
Yeah, that was my thought, too. What if an iPad user hits a page that has a table and each row has a POST button to delete that row? Does it try to hit all those and cache the results and wipe out your database as a result?
-
@mott555 Maybe it hits them via GET and just crosses its fingers?
-
@topspin said in Oh go fuck yourself, Apple:
I know nothing about web stuff, but isn't POST for requests that are explicitly not nilpotent?! As in, you shouldn't randomly POST stuff, ever?
When was the last time Apple followed someone else's standard?
-
@mott555 said in Oh go fuck yourself, Apple:
@topspin said in Oh go fuck yourself, Apple:
hmm, I usually send this with POST data, maybe I shouldn't just POST to the URL without data. durrrrr
I know nothing about web stuff, but isn't POST for requests that are explicitly not nilpotent?! As in, you shouldn't randomly POST stuff, ever?
Yeah, that was my thought, too. What if an iPad user hits a page that has a table and each row has a POST button to delete that row? Does it try to hit all those and cache the results and wipe out your database as a result?
The Spider of Doom
Josh Breckman worked for a company that landed a contract to develop a content management system for a fairly large government website. Much of the project involved developing a content management system so that employees would be able to build and maintain the ever-changing content for their site....
That case was due to NOT using POST where they should, but the same idea, just with TRWTF on the other end of the system.
-
@aygeeplus said in Oh go fuck yourself, Apple:
@mott555 Maybe it hits them via GET and just crosses its fingers?
lolnope
date time cs-method sc-status sc-win32-status c-ip time-taken cs-uri-stem
28-06-18 12:00:08 AM POST 302 0 555.555.555.555 879 /SpecialSearch.aspx
-
This might actually be, ultimately, IE's fault.
IE(version infinity-ago) ignores cache-control headers on GET requests but not POST requests, so many shitty websites use only POST requests for AJAX/iframes/etc.
But also, proximately, what the fuck. Why would you ever?
-
@lorne-kates said in Oh go fuck yourself, Apple:
28-06-18 12:00:08 AM POST 302 0 555.555.555.555 879 /SpecialSearch.aspx
I see the problem. They are using special CSI SVU IP range and that probably breaks IIS.
