I have a list of image urls in a mysql database. When the client sends some GET request to the server, the server responds with a JSON file that will enable the client to build a template and fill tags, so, nothing complicated.
Recently, the images have been secured by password, so, for example, i can't access them anymore with :
http://www.url.com/image
but I have to use :
http://user:password#www.url.com/image
I can't change that since I am not the admin for this images location.
For now, I am doing some dirty substring operations, server side, just after my SELECT request, to add the "user:password#" information to the url string, before sending it to the client.
It works but I think it is dirty and not very secured. What can I do to make it clean ?
Thank you for your help!
Your image service has decided to adopt basic authentication over http. That means they have decided to adopt a protocol that's grossly insecure. This basic authentication needs https to avoid leaking usernames and passwords to the internet.
That's their problem. But if those usernames and passwords are valuable, it is a serious problem.
Your technique of embedding a username and password in the URL is correct. But it is presently deprecated by some browsers; you should avoid relying on it.
Related
I want my app to append query parameters to a given base URL such that when I share the URL with someone outside the app he won't be able to see the query parameters.
When this person clicks on the link leading him to my website I want to deploy a script that using these query parameters. These parameters are specific to a single share. Different link shares will contain different query parameters.
For example: if I send to someone the link "mywebsite.com/?uid=xyz" then I want him to see "mywebsite.com" only. In the client-site I want to be able to fetch the uid value.
Is there a way to hide the query parameter in Android when constructing the URL?
If the answer is no then how can I encode the query parameters in Android and decode them in the client-side in my website, assuming my website contains a one "Contact Form" static page ?
If you want to be sure that query parameters in a URL are not snooped, don't send the URL over an unencrypted channel.
Fortunately, there is an easy way to do this. Use "HTTPS".
See Are HTTPS URLs encrypted?
The caveats:
It is common practice to put Java web services behind a reverse proxy. In this case, the secure endpoint for the connection is typically your front-end web server (e.g. Apache, Nginx, etc). The back-end connection to your actual web service (e.g. Tomcat, Glassfish, etc) uses HTTP and is not encrypted. If someone / something can snoop that network traffic, they can see the URL. Typically this is addressed by using a "loopback" network connection, or similar so that the packets never leave the host that runs the front-end and back-end web services.
Your web browser may need to do a DNS lookup to find the web server's IP address. This interaction happens before an SSL/TLS connection is establish, and could lead to the hostname in your URL leaking. And if it doesn't leak that way, it it is likely to leak because of SNI in the TLS negotiation.
A comment implies that it is better to use POST and put the query parameters into the request body. In fact, that would makes little difference. If you don't use HTTPS, query parameters in a body can be snooped. The only advantage is that request bodies are typically not logged on the server side.
Ah. You have updated your question as follows:
For example: if I send to someone the link "mywebsite.com/?uid=xyz" then I want him to see "mywebsite.com" only. In the client-site I want to be able to fetch the uid value.
That is not possible. The only way you could do that would be to convince the user's browser to hide the characters in the URL. There is no standard mechanism to do that.
You would be better off using a different mechanism to pass the "secret"; e.g. cookies.
If the answer is no then how can I encode the query parameters in Android and decode them in the client-side in my website, assuming my website contains a one "Contact Form" static page ?
Anyway you want! Base64, ROT-13, a decent encryption scheme. However be aware that if your web form (in the user's browser) needs to decrypt the information then the page needs to include the code to do the decrypting AND the decryption key. That means that a resourceful user can figure out what is going on.
I have an Electron Application that needs to connect to an external PouchDB / CouchDB and a FTP-Server to retrieve some data. So in my Code I use
remoteDB = new PouchDB('http://my-Couch-User:my-Couch-Password#123.456.789.225:5984/myDB');
ftp.connect({host: ServerIPAddress), user: 'my-FTP-user', password: 'my-FTP-Password'});
I'm not working with highly confidential data, but having my passwords for external servers disclosed in such an easy readable form gives me the goosebumps.
Does anybody have an Idea how to at least hide them a little bit? (I know there is no way of really securing them under JavaScript)
Consider storing the confidential data in environment variables and access them via process.env.FTP_USERNAME and process.env.FTP_PASSWORD, for example.
Passwords or tokens really shouldn't be hardcoded and readable.
If you have a lot of configuration values, credentials or tokens, then you can consider using dotenv (https://www.npmjs.com/package/dotenv) or something similar.
Edit
Now that we learned about the OP requirements with his comments below this answer...
It is not possible to hide passwords in any application. It will always be possible to extract them.
Consider changing the server side code so that your applications don't talk with the FTP server directly but with a proxy where credentials are not required. The proxy then talks to the FTP server and the credentials will not be exposed.
Consider using a system that provides access via tokens in addition to credentials. You could ask users to login with their personal credentials and the system could generate and send personal access tokens for the server.
if you don't want to have them on the code and you don't want users to login with their own credentials, then I can only think of either having them on a separate file that compiles the info or do a request to a server that generates session data for the app.
But people with a bit of knowledge would still have ways to get the info in both cases.
This is a subjective question, although I believe this is not opinion based. The only reason of asking it here is that I could not find satisfying answer even after reading multiple articles on JWT Authentication.
I recently started learning JWT and found that it is a 3 part token issued by server to client for authenticity along with passing data like user-scope/roles/permission etc in forms of claims.
My question however are:
The claim part of token still is base64 encoded string which can easily be parsed using atob/btoa. So is the transmission really secure ? What is the real gain here ?
There are multiple articles on generating and sending token to UI. However, almost no good articles on what UI does exactly with it. Is it a common practice to decode the token using atob and use the content within it ? Or is there a different way of validating and retrieving data from it.
Is it really secure to transmit data via headers. I mean is it safe against things like MITM, XSS etc.
I would really appreciate some efforts from the expert in resolving these queries ?
For question #1, the gain is not on the client side. If you can't trust what you received from the server, you can't trust it no matter how it's obfuscated/encoded/encrypted/. The point is that you send this token back to the server. On the server, a quick check will tell that this token is legitimate. Imagine a complex login scenario, where MegaCorp looks up permissions for the user across 739 subsystems, combines them into a single payload, and then doesn't have to do that again on further requests. When the client sends the token back, it validates that you are properly logged in and uses the permissions to do further processing.
For #2, you can put whatever you like into this payload, so long as it isn't meant to be too secure. I mostly use it for basic user info and for application permissions. So I can paint the user's name and offer a link to the specific user settings page. I can check whether the user has access to an administrative page or whatever permissions I need to check. While a malicious user can fool the system by manipulating that data client-side, and can therefore, say, see the admin page, when the call goes back to the server to get the data for that page, the token is either illegitimate and the request will be rejected, or it won't contain the proper permissions and, again, it will be rejected.
I don't really know enough about security to attempt an answer to #3.
Some people use JWT only for isLoggedIn, which is fine, but I think misses some useful possibilities. Used properly, this can be the single mechanism to capture user information for both the client and the server. But the important side to my mind is the server. This can be done in many ways on the client. But it's hard to find something better for the server.
The claim part of token still is base64 encoded string which can
easily be parsed using atob/btoa. So is the transmission really secure
? What is the real gain here ?
The transmission is secure (cannot be read/modified by others) if you send the token via https. JWT contains 2 important parts: a payload and a verify signature.
The signature can be produced and verified only by one person and prove that the payload is legit for that person.
Here is a simple use case:
Client send is credential to the Auth server to receive the right to publish something
The server receives the credential and valid them through a complex process then send back to the client a JWT saying: {I give Client the right to publish signed the Auths erver}
The Client store locally the token
When the client needs to publish something he sends the JWT and is work to server B which share the signing key with Auth server.
Server B verify easily the token and publish the work of the client
Another example of usage is authentication via mail only.
There are multiple articles on generating and sending token to UI.
However, almost no good articles on what UI does exactly with it. Is
it a common practice to decode the token using atob and use the
content within it ? Or is there a different way of validating and
retrieving data from it.
In general, the client wants to obtain a token from some server to send it back later. The client cannot verify the signature because he does not share the private key with the server, he is not a source of trust.
Is it really secure to transmit data via headers. I mean is it safe
against things like MITM, XSS etc.
Using https it is safe: Are HTTPS headers encrypted?
I am building my first node.js webapp. I don't need to manage users registrations. I just need an admin page wich easly allow updating the content of some pages.
I have almost finished the development phase but there is something about security I would like to clarify.
ADMIN PAGE: there are 2 level of security:
1) The admin page is linked to mywebsite.com/hexadecimal_string .
Maybe it's very stupid but the admin page is a "secret" page. Linking
it to mywebsite.com/admin is too much common. Do you think that using
an hexadecimal string can be considered a first level of security?
2) Of course there is a password for admin, stored in my database. If
the password is right, a temp cookie is setted. Maybe I should
encrtypt this password while is posted but I'm not planning to use
https. Is there a way, different by using https, to make the posting
of the password more secure ?
CORS: I don't need CORS but there is a thing that is making me crazy:
In the homepage everyone can post some data to server (we are talking about newsletter emails and others personal datas)
suppose someone reads the javascript code of the home page(in particular the ajax urls) in same way and he tries to post data to the same urls but using a personal script that skip the validation phase. Of course I did the validation to server also but I'd like to not accept any req coming from personal scripts written by other than me. The server should respond only to requests coming from my javascripts, tha anyone can run accessing to www.mywebsite.com. All other requests coming from different scripts will recieve 500-server error.
Now, I read about lot's of people that is tryng to ALLOW CORS. So I was supposing that cors is disabled by default but I tried to post data from another website to mine and the data have been sent without problem and the server responds 200. Why? Can I manage this thing?
There are other common things that I need to analyze and manage for security in my situation??
Since you don't want to use https and are looking for an alternative to that I presume you don't want the password to be sniffed in transit. I suggest a simple encryption decryption algorithm might work out for you. For the second issue, you can add a validation string which the client JS will pass along with other parameters while hitting your server API's. If you generate this string each time the client loads some specific page, then duplication of string will also be tackled.
In case you don't want at all to maintain any sort of db on server side, then attach a hidden HTML field to the API hits. This hidden field again you can encrypt and sent. If you broadcast this field periodically from the server, replication of the field will not be possible.
Also in CORS, you cannot request for data from a cross domain. CORS block comes in place when the browser gets a reply back from the server. Only posting of data does not cause any issue.
I'm working on a web app that is mostly static - just HTML/CSS/JS + assets. I'm using a Rack server (Thin, actually) to serve it.
While the app is mostly static, there are a couple of server-side needs that have cropped up along the way. Since the app needs to interact with those needs via JavaScript, I've added Sinatra to the stack to allow me to easily set up some routes to serve as a simple API.
One such API call is to send an email - the web app needs a way to send an email to users. I set up a route (/api/mail) that can be called with a POST that includes a JSON object, and Ruby will fire off an email (via SendGrid).
Here's my issue - by nature, these API calls are public. Most of the time, that is fine - but with the email API, I want to protect it so that nobody can just start sending malicious emails with a simple POST, posing as my app.
Problem is, I'm not quite sure how to authenticate this. The web app itself is the client, not the user, so a password or API key seems worthless, since anyone could just sniff out the POST header and grab the credentials that the app is posting to the API.
Is encrypting everything via SSL my only option, or am I missing some glaringly obvious solution?
At the end of the day, anything you do can easily be scraped. I would do some aggressive rate limiting by ip and session, don't think if anything else would be possible (or effective)