On 2013-03-19 08:52, Chuck Mariotti wrote:
I agree with you that it seems like it is something that is not deliberate
because the IP's are mostly all local, the browser agent is all iPhone with
varying OS versions and Webkit versions... (HTTP_USER_AGENT:Mozilla/5.0
(iPhone; CPU iPhone OS 6_1_2 like Mac OS X) AppleWebKit/536.26 (KHTML, like
Gecko) Mobile/10B146) (I have lots more info if needed, just can't post
public), so either it is phone specific OR the browser agents are forged... But
as you said, impossible(?) to fake the IP address, so unsure why they would
bother faking agents of the same general type (other than making it harder to
block, but that was the purpose they should have mixed it up considerably with
Android, etc...)
An example is that a "user" scans 13 unique codes within a matter of a couple
of minutes (which is pretty aggressive... time between scans is below 40 seconds). They
seem to switch up the sessionID every ~8 attempts...
I should also point out that these are valid requests (they are not random
generated URLs or guessing)... they are valid codes. So they are either really
scanning paper OR they have a valid list of URLs they hit.
My feeling is that it's something wrong with handling the redirects in QR Code
Scanning process which is somehow locking onto the URLs and hitting them over
and over again... specifically on iPhone... I have installed a handful of
scanners but am getting expected results... the developer disagrees that it is
not deliberate...
After you collect the hit, you redirect the user? To a http:// URL, or
to a local app URI syntax (or something that might redirect to a local
URI?)? Or a HTTP page in a new tab?
I'm wondering if the workflow might look like this:
1) User scans code
2) User hits your page and is redirected to a URI: destination (or maybe
even a URL in a new tab?)
3) The tab stays open and gets refreshed, either as the iPhone dumps
Safari's tab cache contents out of memory or the user re-opens Safari
and interacts with another tab.
Now keeping in mind that mobile users tend to be behind NAT, you could
easily have a handful of users scanning your codes (I'd be surprised,
but this is a good problem to have) that have the same or similar IPs
and float between a handful of similar IPs, with multiple devices
coordinating in a very small-scale, unintentional, DDoS.
I've run into this is a user, on a very small scale: When I accept an
online webinar/meeting invitation from a particular site by email, it
takes me to a HTTP URL, which detects I have the application installed
and immediately redirects me into the application. When I next return to
Safari, it reloads the tab and redirects me back into the application.
In this case, the cycle breaks after the meeting has ended, or if I
quickly return to Safari (before the tab cache is dumped) then Safari
presents a blank page but the original URL is still in the URL bar.
It's a longshot, but it's not outside the realm of possibility.
--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren
_______________________________________________
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list
