Some budding hackers may be surprised to learn that browser user agent data is a consideration in network access control systems, but it is commonly employed as an additional validation of a client. Thankfully for us, spoofing the HTTP User-Agent field is easy. Back in my day, we used custom UA strings with cURL, but now you kids have fancy browsers that allow you to override the default.

Let's try to emulate an iPad. Sure, you can experiment with an actual iPad to capture the user agent data, but UA strings are kind of like MAC addresses in that they're easy to spoof, and detailed information is readily available online. So, I'll just search the web for iPad user agent data and go with the more common ones. As the software and hardware change over time, the UA string can change, as well. Keep that in mind if you think all iPads (or any device) are created equal.  

In Kali, we open up Firefox ESR and navigate to about:config in the address bar. Firefox will politely warn you that this area isn't for noobs; go ahead and accept the warning. Now, search for useragent and you'll see the configuration preferences that reference the user agent:

Note that there isn't an override preference name with a string data type (so we can provide a useragent string). So, we have to create it. Right-click to create a new preference name and call it general.useragent.override.

The data type is a string, of course, and the value is the user agent data. Keep in mind, there isn't a handy builder that will take specific values and put together a nicely formatted UA string; you have to punch it in character by character, so check the data you're putting there for accuracy. You could pretend to be a refrigerator if you wanted to, but I'm not sure that helps us here:

I've just dumped in the User-Agent data for an iPad running iOS 9.3.2, opened a new tab, and verified what the web thinks I am:

The Website Goodies page is now convinced that my Kali box is actually a friendly iPad.

While we're here, we should cover ourselves from JavaScript validation techniques, as well. Some captive portals may inject some JavaScript to validate the operating system by checking the Document Object Model (DOM) fields in the browser. You can manipulate these responses in the same way you did for the User-Agent data: 

general.[DOM key].override

For example, the oscpu field will disclose the CPU type on the host, so we can override the response with the following:

general.oscpu.override

As before, the data type is a string. This seems too easy, but keep in mind that the only code that will get the true information instead of your override preferences that are defined here is privileged code (for instance, code with UniversalBrowserRead privileges). If it was easy enough to inject JavaScript that could run privileged code, then we'd have a bit of a security nightmare on our hands. This is one of those cases where the trade-off helps us.