I am interested in filtering traffic comming into Chrome. I've seen WebRequest API and ignoring the fact that it's experimental it seems that you can't stop traffic since events are asynchronous.
I was also exploring the NPAPI plugins for filtering but it seems that they are plugins that need to be registered for particular content type.
Is there any other way for filtering and blocking incoming HTTP traffic in Chrome?
EDIT
I don't know if using a proxy would be a viable option. I am building a software that can be installed on a client machine and this software supports traffic filtering based on custom criteria for IE and FF. I would like to add Chrome support also. Proxy is a third-party app. How would I control it? User would also have to change it's network connection settings.
Related
I am developing a Chrome extension and need to implement an API to change settings in Chrome.
I find all the settings in about:flags page, but I cannot find extension API to get or set.
No, there is not.
The options in chrome://flags are intended for Chrome developers, not for end users. Flags are typically not permanent, as they are used for features that are still under development and testing, or features which are only used for testing. Once testing is complete, the flag is removed.
In short: flags are not a stable interface. Extensions should not depend on features controlled by flags. If a feature your extension needs is only available through a flag, it is not ready for general use yet, and you should wait until that changes.
I added HPKP header to my site, but it is not honored by Chrome or Safari. I tested it manually by setting a proxy and by going to chrome://net-internals/#hsts and looking for my domain - which did not found. The HPKP seems correct, and I also tested it using HPKP toolset so I know it is valid.
I am thinking I might be doing something weird with my flow. I have a web app, which is served over myapp.example.com. On login, the app redirects the user to authserver.example.com/begin to initiate OpenID Connect Authorization Code flow. HPKP header is returned only from authserver.example.com/begin, and I think this might be the issue. I have include-subdomain in the HPKP header so I think this is not the issue.
This is the HPKP header (line breaks added for readability):
public-key-pins:max-age=864000;includeSubDomains; \
pin-sha256="bcppaSjDk7AM8C/13vyGOR+EJHDYzv9/liatMm4fLdE="; \
pin-sha256="cJjqBxF88mhfexjIArmQxvZFqWQa45p40n05C6X/rNI="; \
report-uri="https://reporturl.example"
Thanks!
I added HPKP header to my site, but it is not honored by Chrome or Safari... I tested it manually by setting a proxy...
RFC 7469, Public Key Pinning Extension for HTTP, kind of sneaks that past you. The IETF published it with overrides, so an attacker can break a known good pinset. Its mentioned once in the standard by name "override" but the details are not provided. The IETF also failed to publish a discussion in a security considerations section.
More to the point, the proxy you set engaged the override. It does not matter if its the wrong proxy, a proxy certificate installed by an mobile device OEM, or a proxy controlled by an attacker who tricked a user to install it. The web security model and the standard allow it. They embrace interception and consider it a valid use case.
Something else they did was make the reporting of the broken pinset a Must Not or Should Not. It means the user agent is complicit in the coverup, too. That's not discussed in a security considerations section, either. They really don't want folks to know their supposed secure connection is being intercepted.
Your best bet to avoid it is move outside the web security model. Don't use browser based apps when security is a concern. Use a hybrid app and perform the pinning yourself. Your hybrid app can host a WebView Control or View, but still get access to the channel to verify parameters. Also see OWASP's Certificate and Public Key Pinning.
Also see Comments on draft-ietf-websec-key-pinning on the IETF mailing list. One of the suggestions in the comment was change the title to "Public Key Pinning Extension for HTTP with Overrides" to highlight the feature. Not surprisingly, that's not something they want. They are trying to do it surreptitiously without user knowledge.
Here's the relevant text from RFC 6479:
2.7. Interactions with Preloaded Pin Lists
UAs MAY choose to implement additional sources of pinning
information, such as through built-in lists of pinning information.
Such UAs should allow users to override such additional sources,
including disabling them from consideration.
The effective policy for a Known Pinned Host that has both built-in
Pins and Pins from previously observed PKP header response fields is
implementation-defined.
Locally installed CAs (like those used for proxies like you say are running) override any HPKP checks.
This is necessary so as not to completely break the internet given the prevalence of them: anti-virus software and proxies used in large corporations basically MITM https traffic through a locally issued certificate as otherwise they could not read the traffic.
Some argue that locally installing a CA requires access to your machine, and at that point it's game over anyway, but to me this still massively reduces the protection of HPKP and that, coupled with the high risks of using HPKP, means I am really not a fan of it.
We're investigating porting a fat-client .NET application to be an HTML5-based webapp, but a hangup is that we interface with a variety of usb/serial/shared devices (receipt printers, report printers, specialty archive printers, sigpads, scanners, webcams, etc).
Is there any feasible way to get an HTML5 site the ability to interface with local USB/serial peripherals, or with a local service (e.g., browse to www.site.com/app and have it interact with localhost:1234/api to request things like signatures and send stuff like print jobs)?
The other option I was thinking of is to have a local thin-client type setup, which requests UI elements from the remote server's API, but internally has logic to know what peripherals are doing and passes data via the API.
The least preferential item is to try to write some sort of browser plugin, which is is tied with using a java applet. Silverlight might work, but I haven't researched it too much.
Ideally we'd like to do this to make our app cross-platform, and we're not sure what the best practices are for our situation, or what is the path of least resistance, etc.
Try to embed a web browser into a standalone application and code the interaction in the backend:
Some alternatives:
CEF is cross platform https://code.google.com/p/chromiumembedded/
Old and tried SHDocVw ActiveX for embedding IE using COM on Windows http://msdn.microsoft.com/en-us/library/aa752040(v=vs.85).aspx
You could of course use a local service application to do the dirty work for you and you would have to communicate somehow: WebSockets, AJAX requests. There are ways around the security measures that are coded into modern browsers (cross domain requests and DNS trickery) but the major hurdle will be to get your customers to install a service. If you manage that, then the service could very well serve HTML pages directly and handle requests for peripherals.
I need to reverse-engineer some javascript application which does authorization using facebook auth.
Facebook auth window pops up, asks for my permissions, and gets closed instantly, so I am unable to grasp anything from the performed action, as it's too fast.
The problem is that neither Chrome DevTools, nor Firefox Firebug does display network activity for child windows like OAuth permission.
Is there a way to enable FULL network log? An extension, whatever? (It better be free and easy to use)
If you're using Windows, you need Fiddler. If you're not, you'll have to settle for Wireshark. Wireshark is more-general and an amazing tool, but Fiddler does a much better job for HTTP and SSL conversations like you're going to be examining.
So I have been thinking about building quite a complex application. The idea of building an html5 version has become quite an attractive possibility. I have a few questions about it first however.
My first concern is how reliable the offline application API's are at the moment. I have been looking into this standard: http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html and it looks pretty easy to implement and use, but I am wondering how easy it is to use? And assuming you set up the manifest etc, is the web application just accessed (offline) by going to the same url you originally downloaded the application from?
My other concern is the use of sockets. This offline application still needs to be able to communicate with local servers, I ideally wanted to avoid having to host a web-server, a socket connection however would be plausible. How well do websockets currently work when the browser is offline? Is it possible, to have a fully networked / interactive browser application running even without an active internet connection? (after the app is first downloaded)
Any insight would be great!
That's a lot of questions, you may want to consider breaking it up into more easily answerable portions more directly related to what, exactly, you're trying to achieve. In the meantime I'll try to provide a short answer to each of your questions:
My first concern is how reliable the offline application API's are at
the moment.
Fairly reliable, they have been implemented for a number of versions across most major web browsers (except IE).
is the web application just accessed (offline) by going to the same
url you originally downloaded the application from?
Yes. Once the offline app has been cached, the application is served from that cache. No network requests will be made unless you explicitly request URLs from the NETWORK or FALLBACK sections of the manifest or aren't covered by the manifest at all, apart from to check whether the manifest itself has changed.
This offline application still needs to be able to communicate with
local servers, I ideally wanted to avoid having to host a web-server,
a socket connection however would be plausible.
A Web Socket still requires a web server. The initial handshake for a Web Socket is over HTTP. A Web Socket is not the same thing as a socket in TCP/IP.
How well do websockets currently work when the browser is offline?
They won't work at all, when you've set a browser to offline mode it won't make any network requests at all. Note that a browser being set to offline is not the same thing as the offline in 'offline API'. The offline API is primarily concerned with whether or not the server hosting the application can be reached, not whether the the browser is currently connected to a network or whether that network is connected to the internet. If the server goes down then the app is just as 'offline' as if the network cable on the user's computer got unplugged. Have a read through this blog post, in particular the comments. My usual approach to detecting offline status is to set up a pair of files in the FALLBACK section such that you get one when online and the other when offline - request that file with AJAX and see what you get.
Is it possible, to have a fully networked / interactive browser
application running even without an active internet connection?
Yes, but I don't think that means what you think it does. Separate instances of the app running on different browsers on different machines would not be able to communicate with each other without going via the web server. However, there's no requirement that the web server be 'on the internet', it will do just fine sitting on the local network.