Recently I am doing a research on the request/response model of the facebook mobile app. I am using the fiddler 4 to capture all the http/https conversation from the facebook app on my iphone 4s. What I did was setting my desktop as a proxy and redirecting all the iphone network traffic through it. By the way, I have configured the fiddler so that all the https conversations are also transparent.
One interesting thing I find is that, although I am able to capture all the requests and responses for the graphics and jsons. I never found any request regarding the Comments or Likes, nor can I find any information of the new feed that's in plain text.
My question is, did I miss something or such "plain text" conversations are happening on a different transport layer or with some different protocol?
How am I able to get these conversations in my fiddler?
Thanks
All communication with the server API should be running over HTTPS. It means it's SSL encrypted and you are unable to see the plain text communication on your proxy. That behaviour is on purpose to protect the users data. You surely wouldn't be happy if anybody on a way of packets from your iPhone to the Facebook API's could read your messages for example :-)
You are saying you made "https transparent". I don't know what exactly you mean, but unless you make classical man-in-the-middle attack by faking certificates, you have no chance to see the open text communication of HTTPS. And I think FB has it covered and will detect change of certificates.
Edit: I just have checked it out using Charles proxy and yes, all the communication to the Facebook API is (of course as expected) HTTPS, so you will never see any open text communication.
As you know, you can easily configure Fiddler to decrypt HTTPS traffic.
My first guess is that the "Like" and "Comment" data are transferred over a HTML5 WebSocket. Do you see any WebSockets in the traffic from the application?
Related
Fiddler doesn't show outgoing API requests.
Using IFEO debugger shows localhost requests that are not usefull for me, I need actual domains.
Someone told me that client ignores windows proxy and i need application proxy but client has protection against it so there's even more to it.
Has anyone tracked lol/riot's requests before and know how to do that?
We are developing a desktop application in C++ which is distributed to our customers. It will communicate with the server using REST API over HTTPS. We are concerned about network sniffing software, such as Wireshark. By using such tools, malicious users could record the HTTPS traffic, extract request URL, headers and body and perform requests to our backend REST API server on their own using automated scripts or Postman.
I read an article which suggests that API keys should be used to identify that requests are really sent from C++ application. However, I don't understand how API keys prevent users from sniffing traffic? If API keys are included in HTTP header, they are still easily extracted by Wireshark.
Are there any other ways for ensuring that requests to our REST API server are actually sent from genuine and unmodified C++ application that we developed? How can we ensure that even if attackers use Wireshark, they won't be able to call REST API on their own using Postman (outside of our C++ application)?
Sending the API key inside a TLS encrypted session (HTTPS) is perfectly safe as the headers are encrypted as well. The only thing that you may find in cleartext is the hostname/SNI of the server.
No, there is absolutely no way to make sure, that the requests are sent from the 'genuine and unmodified C++ application'. But if you want to raise the bar and make it way harder for an attacker to e.g. perform a Man in the Middle (MitM) attack and analyze the traffic, you can do following:
API keys are a good thing. Do it.
Pin the certificates to make MitM attack way harder to perform. Wireshark will see the traffic still, but it will be encrypted.
Obfuscate the code, so even a binary analysis becomes harder.
This will not hold back a motivated attacker, but it will raise the bar significantly and unless you are doing banking apps (which I believe you don't, as banks buy themselves security solutions out of the box from some companies specializing in security design), then it may be simply not worth it to go through all the trouble of attacking apps with such protection.
I am currently implementing a Facebook Chat Extension which basically is just a web page displayed in a browser provided by the Facebook Messenger app. This web page communicates with a corporate backend over a REST API (implemented with Python/Flask). Communication is done via HTTPS.
My question: How to secure the communication the Web page and the backend in the sense that the backend cannot be accessed by any clients that we do not control?
I am new to the topic, and would like to avoid making beginners' mistakes or add too complicated protocols to our tech stack.
Short answer: You cant. Everything can be faked by i.e. curl and some scripting.
Slightly longer:
You can make it harder. Non browser clients have to implement everything you do to authenticate your app (like client side certificates and Signet requests) forcing them to reverse engineer every obfuscation you do.
The low hanging fruit is to use CORS and set the Access Allow Origin Header to your domain. Browsers will respect your setting and wont allow requests to your api (they do an options request to determine that.)
But then again a non official client could just use a proxy.
You can't be 100% sure that the given header data from the client is true. It's more about honesty and less about security. ("It's a feature - not a bug.")
Rather think about what could happen if someone uses your API in a malicious way (DDoS or data leak)? And how would he use it? There are probably patterns to recognize an attacker (like an unusual amount of requests).
After you analyzed this situation, you can find more information here about the right approach to secure your API: https://www.incapsula.com/blog/best-practices-for-securing-your-api.html
On my website, there is a web form that users fill out and the data collected gets e-mailed to me. Is it possible for someone to hack the data and get the users' information? Also, my site does not use a secure connection.
It depends on whether the data is logged, or flushed after being emailed.
If it is logged, then theoretically yes, a malicious user could compromise the server and access the logs.
If it isn't, there's still the possibility of your email being compromised, but at some point a line has to be drawn.
It would probably be helpful to see a specific example, or at least a little more details about exactly how this form operates.
If someone uses your site from say an internet cafe then there could be a man-in-the-middle attack where all requests go through some program sitting on the cafes server.
i think if you are worried then you should probably secure at least that page.
If you are not using SSL then its possible for someone to sniff the traffic to your server and collect all the user information thats being posted from their browser. Using an SSL cert and forcing HTTPS will make it much harder (nearly impossible) to catch the traffic on the netwrok.
I am building a iPhone web based app for our execs to view sales data. The app goes over SSL with a typical login page that sets a cookie for the day.
Since the info is sensitive and we have a VPN at work I was hoping as a double precaution I could send all communications with this app over our VPN.
Is there a way I can route traffic over the VPN only for a specific URL? Does anyone have any more info on the "Send All Traffic" in the VPN configuration
Thanks
The app has very little control over the VPN. A properly configured HTTPS site (particularly employing bi-directional certificates) will give you the kind of protection you're looking for your application.
That said, I strongly advocate that business users send all data over the VPN in all cases. This eliminates a wide variety of attacks and provides the opportunity for additional monitoring and protection. Thus, I generally recommend using the "Send All Traffic" VPN configuration. This would allow you to move the app entirely internal, so that outsiders cannot access the login page.
Properly done HTTPS should be sufficient. Provision the phone with a client certificate (there's a tool for that) and ensure the server checks them... and use a revocation list on the server side in case of stolen phones.
Making settings and managing the VPN routers and servers in iPhone is not easy. You should to make some HTTPS settings for this. After this, the client will be able to access your computer. Otherwise iphone vpn will lose its goal to run the server.