I've a web page that has to be opened only via mobile app with webview (or anything the OS uses).
I found some answer where people say to use HTTP_USER_AGENT to check where the request come from, but user-agent is easy editable during the request, so I'm looking for a safer way to do this.
What could be the best approach in this case?
Thank you
You could create a small mobile app which would only run on the mobile phones that you intend to support and the app would generate some temporary tokens and would POST them to the server. The session in the mobile browser would be registered to a WebSocket channel of the server and would update those tokens in real-time. This way, at least the given app is guaranteed to be run on a phone. And if the app is tied to a single session, then it is highly probable that the session would run on the same phone.
If you want to guarantee it, then you can create a browser extension which would communicate directly with your phone app on OS level.
Related
We are developing a web page that use https protocol (two way).
We need to access to the private certificates of the user, because we need sign documents by the user's certificate, so we developed a Java application that communicate with the web by a websoket.
This application will call with a protocol call since the web (same that when you open a pdf on Acrobat Reader from a browser).
So we have to be sure that our web is calling to the native application(only our web). We want develop a system to be sure of that. Our idea:
Send a public key, a signed token by the server's private certificate and a symmetric key (to encrypt websocket communications) to the native application.
Next, we will Check in the native application that the token it is OK with a web service to the server.
After, we will have to open the websocket between the native app and the web, and send the signed document by the native app by this way.
Then sent document to the server.
Is this implementation safe? We will be safe of a man in the middle?
Any suggestion about this solution will be wellcome, because I don't see any weakness but I am not an expert on security.
I know other solutions for this problem, like applets, JavaFX or native messages on Chrome, but I only want to know if these solution is safe.
Thanks to all in advance and sorry if my english isn't the best :P,
I see the following issues
Send a public key and a signed token by the server's private certificate to the native application.
You are calling a local app by protocol. For example mylocalapp://sign?securitytoken=.... You do not control which application is installed on local PC to respond to mylocalapp://. The browser shows an ugly warning because you are leaving the secure environment. An attacker could have replaced the default app, simulate the flow and get all signed documents.
2.Next, we will Check in the native application that the token it is OK with a web service to the server.
To verify identity of server and avoid a ManInTheMiddel attach you need also to set a trustore for your application with the server certificate
Your server needs also to verify identity of client. Are you planning to use TLS two ways also?
After, we will have to open the websocket between the native app and the web, and send the signed document by the native app by this way.
You do not need a websocket. Simply use a URL connection to download and upload the documents.
This solution was used by Spanish ministry of economy when chrome decided to cut the NPAPI support and signature applets began to fail. Now, they have rebuilt the system in this way
Install a local Java application on the user's PC. The application listens on a port as, for example 5678
In your page, javascript connects to the application in the form http://127.0.0.1:5678/sign and sends the data to sign.
The application is local and has no trouble using the operating system keystore, which includes drivers PKCS#11. Perform digital signature and sends the result to the server
The javascript of the page periodically query the result and retrieves it when ready
The security problem is basically the same, but install a server in localhost is harder than replace the local default app.
The solution is called #firma, I guess you probably know it. It is opensource, you can use it
In chrome version 47 they force you to use https to be allow using getUserMedia().
Unfortunately, I can't use https in my whole web, I only use it in the login rest (It a SPA - single page app). So, the address to the web is without https, only the login rest uses ssl.
I use this repo with very little changes:
https://github.com/Jmlevick/html-recorder
My question is if is there any way to use audio recorder in my web app and keep my web address with http and not https? what ideas do you have to overcome this issue?
getUserMedia allows you to listen in to the private conversations of the user. If it were enabled over unencrypted HTTP, this would allow an attacker to inject code that listens in and sends the conversations to the attacker. For example, if you if you are in a private conference room of a hotel with unencrypted WiFi, everybody in the vicinity of the hotel could listen in. Even if your app does not usually deal with sensitive conversations, an attacker could replace your code with theirs in order to listen in at a later time, when another app is in use.
Therefore, getUserMedia is only available from secure contexts. For testing, you can exempt your domain by starting Chrome with --unsafely-treat-insecure-origin-as-secure="example.com", or simply test under http://localhost/.
If you want your app to listen to the user's microphone, you must serve it via TLS. There is no way around it. If there were, it would be regarded as a security hole and fixed in the next version of the browsers.
HINT
You might have to add "http://" on the command line, e.g.:
--unsafely-treat-insecure-origin-as-secure="http://example.com"
Also you can add whiltelist by opening chrome://flags and search for unsafely-treat-insecure-origin-as-secure:
chrome://flags/#unsafely-treat-insecure-origin-as-secure
I am working on a project where i need my mobile application to talk to my web browser on a pc, where both devices are connected over wifi. The app would send data which would be received by the computer browser followed by some client side code execution. The browser then may send some feedback.
My initial approach is to make the app talk to an endpoint which in turn talks to client side of the browser (javascript).
What could be the best approach to do this ?
Update
I am not sure if Socket.io is a possible solution since it requires a server to be hosted. Is it possible to solve this using sockets ?
You've now edited your question to mention P2P. That's quite hard to achieve PHONE TO BROWSER (i.e., by hard I mean 6 to 12 man-months of work - and/or plain not possible). However in MOST situations you can instantly (ie "one line of code on each platform") resolve the problem by using a service like pubnub. Much as nobody has back-ends anymore and everything is just done with parse.com or game center, networking like you mention is now just done with pubunb (or any competitor).
This is an extremely common use case problem - and everyone just uses PubNub as mentioned below or one of its competitors.
These days it couldn't be easier, just use pubnub.com
It's the world's biggest data-messaging service for a reason!
There's essentially no other realistic approach, it's so simple - a few lines of code.
So short answer would be: A real peer-to-peer (P2P) communication is currently not possible with all browsers. So instead you have the following options:
App + Server with a WebUI (maybe)
App + Chrome App (Chrome Apps can start an web server, see http://www.devworx.in/news/misc/chrome-apps-can-now-run-a-web-server-135711.html)
App + WebApp with Plugin (Flash, Silverlight or Java)
I personally would prefer solution 1.
You need a server. If you consider this problem strictly from the typical firewall point of view, a PC or a mobile device are going to ignore connections unless they initiate the connection themselves. So neither the PC nor the mobile device can start a connection with the other.
My understanding is that web browsers do not support standard sockets within javascript. You can use the analagous websocket, but sockets and websockets are not directly compatible.
You can setup a simple server on the PC, and have this server relay messages between the mobile device and the PC browser. Both the mobile device and the PC browser connect to the server. This is basically what an external service will do for you.
PeerJS is what you're looking for:
http://peerjs.com
I have been working on creating an application that sends a string from an android phone to a server and from there sending it to a Chrome extension. I am sitting with a few options to continue, I can convert everything to websockets, I can use normal sockets for android to computer and websockets for extension to server, or I can do some HTTPRequest stuff.
I am looking for suggestions on the best way to pull off this communication. I have a php server an android application and a chrome extension that need to be connected. If there is a way to connect the android application to the chrome extension without the server I would be happy to hear that too.
I need something secure and something that can be organized based on the correct person asking or sending information. So when someone sends a string from the android application the server stores it (probably using their gmail) and when the extension asks for it the server sends it along.
Also could the server just push the string to the extension without the extension calling it? This would occur after the initial websocket connection. I guess it would just store the IP address or something like that.
Any suggestions or comments would be appreciated I am just trying to make the most efficient and secure system I can come up with. I have done a significant amount of research about every aspect so I'm more suffering from information overload then anything.
Thanks in advance :]
Look into Windows Communication Foundation Services (WCF). That's what I have been using for my android applications working with a database - the .NET framework is great, and the services seem to be fairly dynamic.
http://msdn.microsoft.com/en-us/netframework/aa663324
I am wondering how i can send a command (like 1, 2, 3..etc) from my web app (classic asp/asp.net) web page on my android web browser to a windows computer thats on the same LAN network. Kind of like an instant messenger type of thing so that i can design a web page with buttons and each button would send a command back to the computer.
Is that possible? Or do you know any other alternatives to accomplish this same task?
David
If you are looking at using a web server for each system windows system, then the android app simply calls some webpage with the message. The android app would need to keep calling a particular page for 'new' messages using an ajax request. However there are probably other better was of doing this - but it is possible using this method. Another option is each windows system self hosts their own WCF app which receives messages. You still need some central store to make sure all members get the messages unless they constantly poll each other.
Another alternative (and doesn't require polling) is to utilize sockets and simply stream the data back and forth over a port and keep the connection open.