I'm building a mobile application that displays the source of a WAP site. but I am not able to get the html source of my operator WAP site http://divein.tatadocomo.com. I doubt its the user agent that is missing. So can I fake a mobile application to act as WAP browser to extract the source contents. The application is build on MIDP Java 2.0
Or is it something else other that user-agent that is causing the problem?
Nice question, yes there are other factors that an Operator in this case might take into account.
They can determine if you are own their network (i.e. originating IP which you can't change)
They could perhaps be looking at other HTTP headers other than User-Agent. One of them is: Accept header (this tells the server what kind of pages it can accept, e.g. html, wml etc)
Have a look at all the http headers in your browser (using Chrome for example) and see which one's you can play with.
Secondly, hit a site that echo's back all your headers from a mobile device, then emulate all those headers on your pc and see if it works. If it doesn't, then it's most probably your IP.
Related
in our company we need to implement a self hosted Rest Service that has to be deployed in the client workstations in order for our internal web applications to interact with them.
The web applications are in https, and we are not using, at the moment, the CSP headers.
Our concern is whether it's necessary to call the local service also in https or this can ne avoided (and so we can avoid to manage a certificate to deploy in every single workstation).
We made some trials with Chrome and Edge and it seems that the ajax calls are working also in plain http, but we would like to know if that is actually supported or not. Our internal web applications are not using, at the moment, the Content Security Policy headers.
Thank you!
On an HTTPS connection browsers will block HTTP content as mixed content, CSP will not change that. However, Chrome will allow mixed content on http://127.0.0.1 and http://localhost while Firefox will allow it on http://127.0.0.1, see note on https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content.
When you implement CSP you should include http://127.0.0.1 (or http://localhost) for the appropriate directive.
I've got a requirement to detect if a webpage is being served on the internet or intranet, i.e. assuming a url of https://accessibleanyway.com, is the phone connected to the work wifi or to something else like their home wifi or the phone network?
What different ways are there to do this?
(1) Use WebRTC to get the local ip address. Not widely supported
(2) Try to access a local web page using jsonp/cors/iframe
The problem with 2 is that the webpage is https and the local resource is likely to be http which you can't do in IE afaik. If I make the local resource https then it's via a self cert which means installing CAs on the phones (can you buy certificates for the intranet anymore?)
Any suggestions?
The problem with (2) was that the same page was trying to use http and https, and even with an iframe you get issues.
What you could do instead is start on a http loading page, use an iframe to access a local resource which you can only access if you are on the intranet, jsonp will work fine for this. Once that's worked or failed, redirect to your start page with some token in the querystring to indicate that you are on the intranet or not
NB jumping from http to https would probably have some security issues if you are on the same website (authentication cookies being initially visible), but I would have thought it would be fine if you are going to a different one
Obviously there'll be some security needed around the token as otherwise the user could just generate their own but that's a different matter which depends on individual setups. It would obviously have to be generated by a server call, otherwise someone could just read the client code.
NB I think the IP address approach is never going to work as you have no way of knowing what a companies intranet setup looks like until you go there, so it's not a generic answer
I've set up a Raspberry Pi as a Wi-Fi access point. Everything works, including the captive portal. The web browser on each client is redirected to the login page, which functions correctly. I'm looking to modify the configuration of iptables and/or dnsmasq to make the client open a web browser on the captive portal automatically. Starbucks, McDonald's, etc. can all do it; I'm trying to figure out how to do it.
Here, here and here are partial explanations of how to achieve it, but I'm looking to understand it - not merely follow someone else's instructions - so that I can do it myself. I would like to write a HOWTO on the subject, partly because one doesn't exist yet (or if it does then I can't find it).
There are third-party apps such as Wifidog and Coovachilli, which seem to do the job, but I've failed to grasp how they do it. I believe it can be achieved by modifying the configuration of dnsmasq and iptables, but that's as far as I've gotten. it should do something like this:-
1) Regulate the data packets in such a way as to let the client's web browser realize that there's a captive portal; this will cause the client's web browser to open a window and direct it to the captive portal
2) Handle the captive portal; permit login; modify the settings of iptables to facilitate login; etc.
3) Redirect all traffic transparently after the login
Items 2 and 3 aren't a problem. I'm stuck on item 1. All advice is appreciated, including redirection to existing documentation. Thank you.
I do not know how WifiDog and CoovaChilli do their thing, but ChilliSpot (which CoovaChilli was originally based on) did something along these lines:
Open a raw socket bound to the internal interface
Capture all traffic bound to that interface
If it was authorized (eg. logged in), handle NAT and forward on out
If not authorized, block traffic
UNLESS
If it was not authorized AND HTTP, use some custom code to reply to the HTTP GET request with a 301 Redirect to point to the portal page itself, which would then allow for login.
That's the very simplified version of it, but I expect that most other captive portals will use very similar methods (especially the 301 Redirect). The absolute best way to find out would be to read a lot of code :)
Best of luck!
In Firefox or Chrome I'd like to prevent a private web page from making outgoing connections, i.e. if the URL starts with http://myprivatewebpage/ or https://myprivatewebpage/ in a browser tab, then that browser tab must be restricted so that it is allowed to load images, CSS, fonts, JavaScript, XmlHttpRequest, Java applets, flash animations and all other resources only from http://myprivatewebpage/ or https://myprivatewebpage/, i.e. an <img src="http://www.google.com/images/logos/ps_logo.png"> (or the corresponding <script>new Image(...) must not be able to load that image, because it's not on myprivatewebpage. I need a 100% and foolproof solution: not even a single resource outside myprivatewebpage can be accessible, not even at low probability. There must be no resource loading restrictions on Web pages other than myprivatewebpage, e.g. http://otherwebpage/ must be able to load images from google.com.
Please note that I assume that the users of myprivatewebpage are willing to cooperate to keep the web page private unless it's too much work for them. For example, they would be happy to install a Chrome or Firefox extension once, and they wouldn't be offended if they see an error message stating that access is denied to myprivatewebpage until they install the extension in a supported browser.
The reason why I need this restriction is to keep myprivatewebpage really private, without exposing any information about its use to webmasters of other web pages. If http://www.google.com/images/logos/ps_logo.png was allowed, then the use of myprivatewebpage would be logged in the access.log of Google's ps_logo.png, so Google's webmasters would have some information how myprivatewebpage is used, and I don't want that. (In this question I'm not interested in whether the restriction is reasonable, but I'm only interested in the technical solutions and its strengths and weaknesses.)
My ideas how to implement the restriction:
Don't impose any restrictions, just rely on the same origin policy. (This doesn't provide the necessary protection, the same origin policy lets all images pass through.)
Change the web application on the server so it generates HTML, JavaScript, Java applets, flash animations etc. which never attempt to load anything outside myprivatewebpage. (This is almost impossibly hard to foolproof everywhere on a complicated web application, especially with user-generated content.)
Over-sanitize the web page using a HTML output filter on the server, i.e. remove all <script>, <embed> and <object> tags, restrict the target of <img src=, <link rel=, <form action= etc. and also restrict the links in the CSS files. (This can prevent all unwanted resources if I can remember all HTML tags properly, e.g. I mustn't forget about <video>. But this is too restrictive: it removes all dyntamic web page functionality like JavaScript, Java applets and flash animations; without these most web applications are useless.)
Sanitize the web page, i.e. add an HTML output filter into the webserver which removes all offending URLs from the generated HTML. (This is not foolproof, because there can be a tricky JavaScript which generates a disallowed URL. It also doesn't protect against URLs loaded by Java applets and flash animations.)
Install a HTTP proxy which blocks requests based on the URL and the HTTP Referer, and force all browser traffic (including myprivatewebpage, otherwebpage, google.com) through that HTTP proxy. (This would slow down traffic to other than myprivatewebpage, and maybe it doesn't protect properly if XmlHttpRequest()s, Java applets or flash animations can forge the HTTP Referer.)
Find or write a Firefox or Chrome extension which intercepts all outgoing connections, and blocks them based on the URL of the tab and the target URL of the connection. I've found https://developer.mozilla.org/en/Setting_HTTP_request_headers and thinkahead.js in https://addons.mozilla.org/en-US/firefox/addon/thinkahead/ and http://thinkahead.mozdev.org/ . Am I correct that it's possible to write a Firefox extension using that? Is there such a Firefox extension already?
Some links I've found for the Chrome extension:
http://www.chromium.org/developers/design-documents/extensions/notifications-of-web-request-and-navigation
https://groups.google.com/a/chromium.org/group/chromium-extensions/browse_thread/thread/90645ce11e1b3d86?pli=1
http://code.google.com/chrome/extensions/trunk/experimental.webRequest.html
As far as I can see, only the Firefox or Chrome extension is feasible from the list above. Do you have any other suggestions? Do you have some pointers how to write or where to find such an extension?
I've found https://developer.mozilla.org/en/Setting_HTTP_request_headers and thinkahead.js in https://addons.mozilla.org/en-US/firefox/addon/thinkahead/ and http://thinkahead.mozdev.org/ . Am I correct that it's possible to write a Firefox extension using that? Is there such a Firefox extension already?
I am the author of the latter extension, though I have yet to update it to support newer versions of Firefox. My initial guess is that, yes, it will do what you want:
User visits your web page without plugin. Web page contains ThinkAhead block that would send a simple version header to the server, but this is ignored as plugin is not installed.
Since the server does not see that header, it redirects the client to a page to install the plugin.
User installs plugin.
User visits web page with plugin. Page sends version header to server, so server allows access.
The ThinkAhead block matches all pages that are not myprivatewebpage, and does something like set the HTTP status to 403 Forbidden. Thus:
When the user visits any webpage that is in myprivatewebpage, there is normal behaviour.
When the user visits any webpage outside of myprivatewebpage, access is denied.
If you want to catch bad requests earlier, instead of modifying incoming headers, you could modify outgoing headers, perhaps screwing up "If-Match" or "Accept" so that the request is never honoured.
This solution is extremely lightweight, but might not be strong enough for your concerns. This depends on what you want to protect: given the above, the client would not be able to see blocked content, but external "blocked" hosts might still notice that a request has been sent, and might be able to gather information from the request URL.
When I try to load a wap site with PHP HTTP request from my PC, host of the web site recognizes that I'm sending the request from a PC and redirects me to their actual web site and I can't load the wap site. Is there a way to behave like a mobile browser and prevent this redirection? Although an answer regarding any programming language is ok, a php specific answer will be better.
This behavior is normally dictated by the User-Agent string on the HTTP request. You can usually spoof the User-Agent string, and replace it with the user-agent of a mobile device, or if you're using Firefox, you can download a User-Agent Switcher plugin.
Change your user agent.
This site is helpful too as many sites use this code or similar to identify mobile devices.