I am planning a Cordova mobile application (a Meteor.js app to be precise) and I need to POST/GET some sensitive data from a remote server securely.
When the request is pointed at https endpoint is it secure? My guess is that it does not work this way.
Just to say - I have read some SO questions and searched google but most of them refer to CORS problems, which I am not facing.
Thanks for any help.
Yes and no
Sending data to a https server is secure?
Yes if you are sure that you are sending the data to your server
But, you might be connected to a public wifi, and somebody could be doing a man in the middle attack, so you think that you are sending your data to your sever, but the hacker is getting the data instead.
To avoid this, you can do server certificate pinning, there are a few plugins available, so you make sure the server where you are sending the data is really yours (comparing certificate fingerprint or checking some of the values)
https://github.com/EddyVerbruggen/SSLCertificateChecker-PhoneGap-Plugin
It depends on what you need. Https (TLS) will provide your mobile users with the certainty that they are communicating with the server that is identified by the certificate. It will also encrypt the communication between the server and the mobile application so no one can listen in.
It won't authenticate your users and allow you to serve certain data to specific users only. You'd need some kind of authentication scheme for that.
It won't protect you from XSS, CSRF, SQL injection or other attacks either. So it very much depends on what your requirements are, but https by itself is not enough to protect a website.
Related
I'm developing a web service that have following structure:
Web Server: this is implemented with NextJS which do Server-Side Rendering and serve server-side rendered webpage data to Client.
API Server: and this one is implemented with NestJS. Clients will send graphql queries/mutations to this server.
Client: any clients can visit my web service and sign in (or sign up)
and I want to implement authentication feature for my web server, but problem is came up here. how can I share the auth data between Web Server, API Server, Client? if you signed in on your own browser, eventually a signing request will be sent to the API server.
but there's literally no way to know whether the client is signed in or not from Web Server. I mean, auth data (whether if user has signed in or not) will be stored only at API Server.
I had searched and spent a lot of time about this and I've got an answer that I have to use JWT Token but there were several ways to store it:
Storing it on clients' web storage: I don't think this can be an answer since the Web Server shouldn't able to get clients' web storage data. this means SSR (server-side rendering) wouldn't work well.
Storing it on Cookie: this is bad too. because we send a signing in request to the API Server that will be on different container (or server) and domain. we cannot set cookies from different domain with proper way. and if we get token and store it cookies directly from client side (setting cookie from javascript), It will be really huge security issue since attackers can take users' token with XSS.
Using Cookie but set from other subdomains with specifying Domain: we can specify domain for setting cookie. as far as I know, a response from api.example.com can set cookies for example.com with specifying Domain property of Set-Cookies value. read this
yeah, method 3 seems pretty neat to have but I absolutely don't know that setting cookies from another sub-domains will cause big security hole. my web service will process about users' money so security issues will come very critical.
someone I know advised me that I can use reverse proxy with paths not domain. I mean, if API Server was serving on api.example.com, we can serve it on example.com/api/* so now we can share the cookies between all the server and client. but we should store cookies on web storage too since cookies will be flagged as HttpOnly. this will cause increasing complexity of development.
In this case, which method will be the best answer for my case? are these methods I've mentioned above are really safe to do?
I have a WebApp(PHP) to which the user sends requests to my server, it processes this data and queries on a social network and returns the information to the user.
But I'm having problems where social networks are blocking the IP of my server because of the volume of queries.
Below is my current flow:
I would like to know if there is a way to return this information to my user's browser and make queries from his computer, since it is a new and residential IP.
I do not know if you can make a proxy server with websocket where you would use the user's machine to send the requests.
Here is the flow you want:
Maybe have some way using websocket with a node.js server.
Thank you very much in advance.
You cannot use a client side proxy as such. Protocols built on top of connection-oriented(TCP) protocol will need a valid IP to get response. Establishing a two-way connection will become difficult once you send different request IPs. Even if you are able to do this by some kind of IP spoofing, which I am unaware of, you'll most likely will not be able to have the solution at scale for your app's users.
The best known method would be to use some kind of desktop based solution for such problems and thereby having organic request IPs. If that is not what you want, then you can use proxy servers, that might even be good if you have fewer users, but that might not scale.
I would like to encrypt ajax post and get request with javascript.
The flow should be -
Server generated private and public key on request
Server sends the public key to client
Client encrypts the data with public key
Sever decrypts the data with the private key
I know SSL is an option, but my application is a small plugin which can be installed on any website that allows a user to purchase products on that website. Is there a way i can encrypt all the data at front end and decrypt at back end.
Thanks in advance!
Generally speaking, in browser cryptography can be considered a bad idea. Sending the data over ssl-tls would likely be much more secure than a home-brewed crypto solution, like you seem to be suggesting. This can be considered especially bad when transmitting data like credit card info, as it appears you will be.
http allows for extremely easy man in the middle attacks to eavesdrop on any data being sent either way, so there would almost certainly be no secure way to transmit the keys in the first place, let alone the secure information.
If you really really want to go this route, then have a look at crypto-js.
This is not a good idea, and you should use SSL. Probably hence the downvotes.
Considering your use case, the best way to do this would probably be to host your own central service with SSL enabled, and route all ajax requests to your service, not theirs. Their servers could then poll your server using your SSL certificate, to view any relevant information. So you would be acting as some sort of centralised API, with both the clients and businesses connecting. You still need to consider however, that any information sent in the clear, ie over http, not https, can be tampered with before it reaches the user.
As far as I am aware, no, you cannot generate SSL certificates on the fly.
I am about to create a API for my web service. Now it's time to think about security.
There will be multiple clients accessing my API, however their all created by me, so no third party clients.
For now I planned a mobile App (Phonegap / JS), a web app (Also JS) and a Chrome App (also JS).
Sadly I don't have the possibility to use HTTPS for my API requests. Thats why I thought about oAuth 1 for security.
My question now: How safe is it to use oAuth in combination with JS, because the Secrets will be stored client side.
Is oAuth a good decision or could anybody recommend a alternative?
Thanks a lot!
Sorry, I've got bad news for you.
oAuth is not safe at all. You need to use SSL. The only way to be secure is to have a third party, that is trusted by the web browser vendor, provide a certificate signed to prove that you are who you claim to be. Without that, anybody on the same LAN as the user can easily hack into your system.
Also note that oAuth 2.0 actually requires an SSL connection anyway.
Finally some more bad news, you cannot store any secrets client side. Client side is controlled by anyone who uses your app, and they can access all secrets you store there. It is impossible to change this, SSL won't help either.
The takeaway is:
you need to use SSL, there's no alternative.
you must not store any secrets client side. All secrets must be server side.
Is there a norm for AJAX security?
When making an XMLHttpRequest, if querying an HTTPS url, will the browser handle all the certificate business and properly encrypt the request (or use an already existing authenticated tunnel)? Are there any security flaws in this model?
Then there's also user authentication issues with AJAX. This made me think that using the user's password to encrypt part or all of an AJAX request could solve some authentication issues. I've seen some impressive javascript based encryption tools. It seems like there'd be lots of potential there to build a single system that takes care of both encryption and authentication(host level and application user level). I have however not seen anything that seems 'tried an true'.
My question can be summed up as:
Is there a norm for secure AJAX either
using browser technologies or client
side javascript? What
is it? And if not, what's preventing
us from building one using javascript?
Thank you, as always.
SSL through HTTPS is sort of a cooperative venture with the destination server. The destination server will report its identity with its identity certificate (sent back to the client). This is part of the protocol that will encrypt the data stream between the client and the server.
However, this just encrypts the stream, it does nothing about several other security issues. Identification and authentication of the user entity making a request is handled through other means. If you're encrypting the stream with SSL, it should be safe to use HTTP basic auth. After that, the response to authentication should be a session id sent back to the client that will pass it back on all subsequent requests. Application servers typically manage the creation of those session ids.
Ajax does not inherently introduce new
security vulnerabilities in the realm
of web applications. Instead, the
applications face the same security
issues as classic web applications.
Unfortunately, common Ajax best
practices have not been developed,
which leaves plenty of room to get
things wrong.
from: http://www.securityfocus.com/infocus/1868
Basic authentication makes sense. I found this article explaining how to do it.
I somehow still have this desire to not use all the browser technologies and encrypt/authenticate things myself. Not sure if that would make any sense. Key caching would be hard to accomplish.
I'm still looking to find out if this (SSL + using basic auth in ajax calls) is the norm.