Fwiw, from my readings of similar cases, this seems similar to how the courts read the law. Any access you can achieve without material deception is valid. There was a case on here a while back where a couple of reporters filed a FOIA request and the city accidentally put records not meant for release in the Dropbox folder. Reporters downloaded the accidentally-added files, city sued. The city ended up settling because it looked like the court was going to rule against them.
The court's logic was basically that by allowing access to the information, you have de facto authorized the user to access it. It would be impossible to tell whether you can legally access any information if the counterparty can give you access and then decide you shouldn't have seen it when you do access it.
The website is at fault. This is no different than lying about your religion to bypass a discriminatory shop owner.
A naive generalization might say that "lying" by setting a header = illegal. But clearly there is a difference between setting the Authorization header and setting the User-Agent header.
But what about headers that are not so well-defined? What about custom headers?
I'm not disagreeing with you, but these are the first questions that come to mind.
It seems that a judge would have to carefully consider the design of the system, and whether the vector that granted access was something that was clearly negligent on the part of the site owner, or was truly an attack vector and deemed illegal. But it seems difficult to formulate a universal test for this.
No. If you falsify information indicating that you have authorization to access the site, it doesn't matter what header it's in. Conversely, if you falsify information that has no bearing on whether you have authorization to access the site, it also doesn't matter what header it's in.
You are either authorized to access the site (or URL, or whatever) or you are not. What tools you use to do so are only relevant if they cause you to generate accesses (eg network requests) that you are not authorized to make. By construction, configuring one tool to generate accesses as they would have been generated by another tool does not produce unauthorized accesses unless that other tool's normal accesses would be themselves be unauthorized.
Ahh, but here's where things get tricky. Who decides that the information has no bearing on whether you have authorization to access the site?
Imagine a situation where a very poorly designed site allows "My-Obscure-User-Agent", but denies all other User Agents. This is obviously a horrible design, but if the intent of the developer was to authorize access to a specific set of internal clients, identified by a unique/non-standard user-agent, how would you classify the act of changing one's browser settings to send the accepted agent?
User Agent is a great example of something that has a pretty well-defined purpose (and that purpose has nothing to do with authorization), but has also been misused by naive or lazy developers to control access to sites.
> to authorize access to a specific set of internal clients,
Are you, the person, authorized to access the site? If yes, setting a User Agent header to "My-Obscure-User-Agent" is truthful (insofar as it bears on whether you (the person) are authorized), regardless of whether you are using the prescribed internal client. If you are not authorized, the use of said internal client doesn't change that.
Edit: as a analogy, suppose you took a job and your employer provided you with a uncomfortable uniform jacket which your employment contract stipulated you must wear when on the job. If you acquired a more comfortable jacket and dyed it to resemble the uniform, your employer would (arguably) be within their rights to refuse you access (blocking by user-agent), but if they let you in, that does not mean you have entered (the employee-only portions of) your workplace without authorization. Same applies to cars, phones, power tools, etc; you may have done something wrong by bringing them to work, but that something is not unauthorized entry.
> configuring one tool to generate accesses as they would have been generated by another tool does not produce unauthorized accesses unless that other tool's normal accesses would be themselves be unauthorized.
Therefore: When you generate a request that spoofs the obscure user agent string, it is authorized only if you were also authorized to use the obscure agent. The string is a secret like any other, even if it's a secret shared by the entire group of people who were provided with the obscure agent.
On the other hand, is it really a secret if the agent tells it to every server that the agent connects to? At some point it's not a secret if little care is taken to protect it (and the name of the header has some bearing on what care is taken, for example whether it ends up stored in clear text in access logs...).
"it is authorized if and only if you were also authorized", but otherwise yes, exactly.
| A | B |A-only-if-B|A-if-and-only-if-B|
|false|false| true | true |
|false|true | TRUE | FALSE |
|true |false| false | false |
|true |true | true | true |
However, if the columns of your matrix were modified to compare "if" versus "[if and] only if" (where square brackets represent an optional component that does absolutely nothing), I'd agree with the logic, being analogous to the difference between OR and XOR (for the boolean sense of OR, not the English sense which is akin to XOR).
And now I'm not sure I'm not the one who isn't reading things properly. (And that sentence probably doesn't help matters.)
I'll point to (the "only if" part of) https://en.wikipedia.org/wiki/If_and_only_if#Distinction_fro..., which I think agrees with me and disagrees with you, assuming I'm not misreading one or both.
Interesting test. What if you set your user agent to chrome instead of firefox and that grants you access to a website?