I wrote a little webapp for secure message transfer to learn more about encryption, and wanted to show it to my friends and let them play with it a little, so I hosted it on my little server, and was shocked to find that the Web Crypto API (which I worked my ass off to get to work because it is not very specific in its error messages) REQUIRES SSL ( kinda defeats the purpouse of implementing your own encryption scheme in browsers)!
I already have another API running on that server with SSL, but instead of merging them I wanted to ask: Is there a way to circumvent the secure socket requirement of Web Crypto API, or is there another library out there which allows me to use the same or similar functions in a non-secure context?
The WebCrypto API specification(https://www.w3.org/TR/WebCryptoAPI/ ) does not restrict to SSL, but browser implementations require a "secure origin"
For example, Chrome requires https , wss, localhost or an extension. See https://stackoverflow.com/a/46671627/6371459
You would need to set up a SSL connection in order to use webcrypto. If you want to use another library (forge, pki.js, etc.) you will not have this restriction, although it is advisable to use SSL / TLS when using cryptography.
Although I haven't tried this, you could use a shim. https://github.com/vibornoff/webcrypto-shim
A shim is a javascript file that does the same thing as the built-in method.
It's used for older browsers that don't support the new methods.
Related
I am building an application that has auth system and a lot of post requests,
I want to know how to make my backend endpoints accept only requests that are coming from my application, not from anything else like Postman.
For example, if a user submitted a registration form, a post request is sent to my backend with user info, how can I make sure this post request is coming from my application?
What I was thinking of, is saving a secret on the client’s side that is to be sent with each request to the backend, so that I can make sure the request is coming from my app.
I think SSL pinning is meant for this.
I know that anyone can access my app source code if they extract the APK file.
I want to make sure that no one can alter or steal my source code.
I read that I can make my code unreadable by Obfuscating it ( I still need to figure out how I am going to do that on my EAS build ), is this enough?
And I have to use JailMonkey to detect if the device is rooted.
I am using Expo secure store to save my sensitive info on the client side.
Is this approach good enough, is there anything I am missing?
I have zero information about security, this is just what I learned through searching.
Let me know if you have better suggestions.
Thank you in advance.
The Difference Between WHO and WHAT is Accessing the API Server
I want to know how to make my backend endpoints accept only requests that are coming from my application, not from anything else like Postman.
First, you need to understand the difference between WHO and WHAT is accessing the API Server to be in a better position to look for a solution to your problem.
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
So think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
When you grasp this idea and it's ingrained in your mindset, then you will look into mobile API security with another perspective and be able to see attack surfaces that you never though they existed before.
Certificate Pinning and MitM Atacks
What I was thinking of, is saving a secret on the client’s side that is to be sent with each request to the backend, so that I can make sure the request is coming from my app. I think SSL pinning is meant for this.
Certificate pinning on the mobile app side serves to guarantee that the app is talking only with your API server and not anything else, like when a MitM attack occurs and the app has its requests intercepted, and potentially modified and/or replayed, or simply saved to later extract the secrets from it.
Pinning doesn't guarantee to your API server that the request is coming indeed from what it expects, a genuine and unmodified version of your mobile app, "unless" you implement mutual pinning, that isn't encouraged to do so, because you will need to ship the private key for the API server certificate in the mobile app. Even if you do so, all an attacker needs to do is to extract the private key and will be able to communicate with your API server like if it was your genuine mobile app.
I don't have an article to implement pinning on a react-native mobile app but you can take a look to the one I wrote for Android to understand better all the process. Read my article Securing HTTPS with Certificate Pinning on Android on how you can implement certificate pinning and by the end you will understand how it can prevent a MitM attack.
In this article you have learned that certificate pinning is the act of associating a domain name with their expected X.509 certificate, and that this is necessary to protect trust based assumptions in the certificate chain. Mistakenly issued or compromised certificates are a threat, and it is also necessary to protect the mobile app against their use in hostile environments like public wifis, or against DNS Hijacking attacks.
You also learned that certificate pinning should be used anytime you deal with Personal Identifiable Information or any other sensitive data, otherwise the communication channel between the mobile app and the API server can be inspected, modified or redirected by an attacker.
Finally you learned how to prevent MitM attacks with the implementation of certificate pinning in an Android app that makes use of a network security config file for modern Android devices, and later by using TrustKit package which supports certificate pinning for both modern and old devices.
Bypassing Certificate Pinning
I think SSL pinning is meant for this.
The good news is that you already learned how good pinning is to prevent MitM attacks, now the bad news is that it can be bypassed, and yes I also wrote an article on how to it on Android (sorry to not be specific on react-native). If you want to learn the mechanics of it then read my article How to Bypass Certificate Pinning with Frida on an Android App:
Today I will show how to use the Frida instrumentation framework to hook into the mobile app at runtime and instrument the code in order to perform a successful MitM attack even when the mobile app has implemented certificate pinning.
Bypassing certificate pinning is not too hard, just a little laborious, and allows an attacker to understand in detail how a mobile app communicates with its API, and then use that same knowledge to automate attacks or build other services around it.
Code Obfuscation and Modifying Code
I know that anyone can access my app source code if they extract the APK file. I want to make sure that no one can alter or steal my source code.
Sorry, but once you release it to the public is up for grabs for everyone, even if heavily obfuscated its still possible to modify it statically or during runtime.
I read that I can make my code unreadable by Obfuscating it ( I still need to figure out how I am going to do that on my EAS build ), is this enough?
No, you can use the best obfuscation tool, but then an attacker well versed in deobuscation techniques will be able to understand your code and modify it statically or at runtime. Several open-source tools exist to ake this easy, and if you read the article to bypass certificate pinning then you already saw an example of doing it at runtime with Frida:
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
RASP - Runtime Application Self-Protection
And I have to use JailMonkey to detect if the device is rooted.
Using Frida the check can be modified to always return that the device is not rooted. Also JailMonkey may not detect all ways used to hide that a device is rooted, and this a moving target, because hackers and developers are in a constant cat and mouse game.
Sensitive Info Security
I am using Expo secure store to save my sensitive info on the client side.
Even when a secret is securely stored it will need to be used at some point, and the attacker will hook Frida to this point and extract the secret or do it in a MitM attack.
Possible Solutions
Is this approach good enough, is there anything I am missing?
From all I wrote it looks no matter what you are doomed to failure in properly secure your sensitive info and to guarantee that your API server knows that what is making the request is the genuine mobile app it expects, but security its all about of applying as many layers of defences as possible, like done in medieval castles, prisons, etc., because this will increase the level of effort, time and expertise required to succeed in an attack.
You now need to find a solution that allows you to detect MitM attacks, tampered and modified apk binaries, Frida present at runtime and that can deliver a runtime secret to mobile apps that pass a mobile app attestation that guarantees with a very high degree of confidence that such threats are not present. Unfortunately I don't know any open-source project that can deliver all this features, but a commercial solution exists (I work there), and if you want to learn more about you can read the article:
Hands-on Mobile App and API Security - Runtime Secrets Protection
In a previous article we saw how to protect API keys by using Mobile App Attestation and delegating the API requests to a Proxy. This blog post will cover the situation where you can’t delegate the API requests to the Proxy, but where you want to remove the API keys (secrets) from being hard-coded in your mobile app to mitigate against the use of static binary analysis and/or runtime instrumentation techniques to extract those secrets.
We will show how to have your secrets dynamically delivered to genuine and unmodified versions of your mobile app, that are not under attack, by using Mobile App Attestation to secure the just-in-time runtime secret delivery. We will demonstrate how to achieve this with the same Astropiks mobile app from the previous article. The app uses NASA's picture of the day API to retrieve images and descriptions, which requires a registered API key that will be initially hard-coded into the app.
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
short answer you can't.
I want to know how to make my backend endpoints accept only requests
that are coming from my application, not from anything else like
Postman
the only thing you can do here is cors Cross-Site Request Forgery Prevention. Y to stop other servers from calling your api.
and you can't make only your application communicate with the server
you can hard code(parameters in the request) in the application to send to the server.but hackers can listen to request made from devices
I know that anyone can access my app source code if they extract the
APK file. I want to make sure that no one can alter or steal my source
code.
short answer you also can't
you can use ProGuard(native code) to obfuscate on native android and ios have compiled binary on release but those are not to js
so basically anyone can read your bundle js in plain text editor.
maybe in the future facebook can make something for hermes.
Reading the official documentation for Tumblr.js, it seems to require Node.js. I'd like to trigger a dialog box and let my app access the user blog. Can I make calls with vanilla JavaScript? I'd appreciate your help. I've been looking around the web and there is little information. Thanks.
HTML
<button onclick="loginTumblr();"> Connect Tumblr </button>
JS
function loginTumblr(){
//get user info + token
}
The answer is "probably," but it certainly won't be secure. Accessing an API from from the client side is risky because you'll have to expose your app's private credentials to the end user.
What you said regarding needing node is not necessarily correct; you could use any server side scripting (e.g., PHP) to safety call the api.
In all cases, make sure you are not exposing your keys or endpoints where other people could use your keys to access your personal account.
If you learn OAuth and CORS, you might be able to write an axios or fetch client. Node's "request" module is not easy to reverse engineer into client-side JS code. The browser versions I've seen don't support the OAuth addon it uses.
If you deploy to now.sh or a VPS, or write an Electron desktop client, you could use the node, golang, or python clients in the backend to proxy tumblr requests.
If you deploy to netlify, you could use the node or golang netlify functions to proxy tumblr requests.
If you deploy to any VPS environment or use serverless/lambda/cloudfunctions, you could proxy tumblr requests in most of the available cloud libraries.
I suspect you could compile the golang or c client to webassembly and expose their functions to JavaScript, but I don't recommend trying this.
Is it feasible to make access from particular environments, such as countries, operating systems, and browsers denied in Node.js and Express? I'm now constructing a web service, but must implement such filters before launching it for some reasons.
I use Node.js v0.10, Express v3.x, and would deploy on heroku. So here's my question:
Is it feasible to implement such filters in my deploy environment, and if it is, how can I do?
Is it feasible to implement such filters only on some specific services, such as comment sections?
I also wonder how secure and robust it can be to have access from those countries denied successfully.
(This is not a heroku question, and in my humble opinion not a node nor javascript question well. This is more likely an http and/or tcp question).
You can filter by these, but beware: it is not secure at all.
Detecting the user's country is usually done by ip (which you can get with req.ip) which is later converted to a location (with some ip/geo service, e.g. MaxMind).
Detecting the browser is done with the User-Agent http header. This is accessible with req.headers['user-agent'].
Detecting the OS is also done by parsing the user-agent header. There are other ways of doing this (passive os fingerprinting -- http://lcamtuf.coredump.cx/p0f3/) but these are probably not deploying on Heroku.
Note that in order to avoid filtering by country, the user can simply access your web server using a proxy in an allowed country. Also, since user-agent is a string the client sends, they can send whatever they want and fake any browser/os.
It really depends on how strict your "filtering security" requirements are.
I'm about to create a JavaScript-based client for a RESTful webservice. The client should facilitate access to the webservice and wrap some raw HTTP calls into more "candy" functions and objects.
I'm intending to use this client library for node.js-based applications as well as for PhoneGap. So, I don't have to care about the Same-origin-policy. However, dispatching HTTP requests is totally differnt in PhoneGap and node.js.
Now I'm wondering how I can implement a client library in JavaScript, that is portable between different "platforms" (node.js, PhoneGap, perhaps later even browers)?
Thanks in advance
You might try this emulation of XmlHttpRequest under nodejs but you still may need to special-case your client library to operate under PhoneGap (and other browser-based JavaScript platorms) and nodejs.
One way to do this would be to check the contents of 'window' which is undefined by default under nodejs, or 'global' which is (should be) undefined in a browser.
EDIT
It appears I spoke(wrote) too soon. Check out abstract-http-request which while not explicitly supporting PhoneGap, might give you enough to work with.
Phonegap is basically just a browser. So if you want to get around the same origin policy you might want to take a look into different phonegap plugins (GapSocket) to handle your own communication.
REST is an architectural style for designing web services. A web service doesn't have to use HTTP to be RESTful, though a large proportion of them do. To be RESTful, an HTTP-based web service has to rigorously leverage HTTP's resource names (URIs), operations (GET, PUT, DELETE, etc), error codes (404, 200, ...), and so on. This means that any (HTTP-based) REST client framework can interoperate with any (HTTP-based) REST server framework: if it doesn't, something's probably wrong. So your problem decomposes into finding a good generic REST client framework and one or more generic REST server frameworks.
For node.js based web services, take a look at the Geddy server-side framework (here's the documentation).
For a PhoneGap REST client, you could try the Force.com JavaScript REST Toolkit (and see this extension).
Disclaimer: I have only read about these frameworks, not used them.
I know, it looks strange, but I need to sign some data on client-side using javascript only, no ajax backdoor to server-side openssl available. Could someone suggest some client-side solution to sign data using private key? Is it possible?
Thanks.
Found great signing tool. It implements RSA-SHA1 (works perfectly) and RSA-SHA256 (works strange), and allow both to generate signature using private key and to verify signature using certificate.
I've gone down the same road as you, you're probably better off implementing something like oAuth.
The problem with what you're proposing is that there's absolutely no reliable way of storing the private key on the client machine, nor of now securely getting the public key back to the server other than HTTPS (and if you're using HTTPS, what's the point of this?)
If you really want to continue, there are some implementations out there: http://shop-js.sourceforge.net/crypto2.htm
And you probably want something horribly annoying like PersistJS (http://pablotron.org/?cid=1557) to try and save the private key as long as possible.
The W3C Web Cryptography API may be able to help. Can I use indicates modern browsers now support it.
For additional digital signature support, look at GlobalSign/PKI.js
PKIjs is a pure JavaScript library implementing the formats that are
used in PKI applications (signing, encryption, certificate requests,
OCSP and TSP requests/responses). It is built on WebCrypto (Web
Cryptography API) and requires no plug-ins. http://pkijs.org
Web Crypto appears to be the answer. Here is a tutorial (not mine). As for the comment, if you are using https, why do you need signing - these are needed for two different purposes. In infosec lingo, the former gives confidentiality and the latter non-repudiation.