i have a question if using SSL will encrypt both the query string and the Post request body which contain the fields values ?
and if the answer is yes,,
Then does this mean that i can be 99% confidence than an attaker will not be able to modify both the query string & the post body request?
BR
Then does this mean that i can be 99% confidence than an attaker will not be able to modify both the query string & the post body request?
SSL only encrypts and hide the information from a third party. However the hackers own request he can do whatever he wants with them, even if they are sent encrypted. As I said SSL only protects against a third party, not anything else.
A golden rule in all web development is, NEVER trust input data, Encrypted or not.
even if the attacker is Authenticated using a username and password to my web site.
The hacker can send whatever he see fit to the server, his request will be encrypted and protected against a third party, but he can send just whatever he want and your code, if you do not folow the line of never trust input data, he might breach into your server yeah.
So yet again SSL ONLY protects against a third party ( and even that some times not )
If you're using SSL, then yes, you can be sure an attacker will not be able to modify the query string or post data. SSL authenticates the server to the client to prevent anyone successfully impersonating your server. It also encrypts each message sent back and forth using the server's private X.509 key, so that no intermediary can decipher them.
Related
I am using Restful api in CodeIgniter. Now I want to give api to third party, so I want to secure that api I am using digest, when I hit the api
in the browser a pop up comes which ask about username and password.
So I want to ask how to pass username and password in url to that it works.
Thank you in advance and sorry for the bad English
This doesn't directly answer you question but it does provide an alternative.
In my experience with API's you secure them with a HMAC. This is basically a hash that is generated using some data unique to the request, a timestamp and a private key. This hash along with the data used to create it will be passed to your API - NOT the private key - this data can all be sent in the headers of the request. When your API gets this data is uses the unique data, the timestamp and the private key to create another hash. The hash from the header and the newly created one are then compared. If they match you can be sure that the same private key was used to generate them. This saves sending any usernames/passwords over the internet.
I would also recommend that your server is setup to only serve HTTPS, this will help prevent man in the middle attacks.
This is a library that I have written for this very purpose.
https://packagist.org/packages/mardy-git/hmac
I hope this helps.
I'm currently working on a single page application that talks to a REST api hosted on a different server and protected with SSL.
I am wondering if I should set an SSL certificate on the server that serves the single page application or if simply setting it on the back end server is enough, by considering the following:
The single page application is an endpoint for reset password links with a confidential token in the query string. These links are sent by email to my users. When a user clicks on the link, his browser requests the single page application. The GET request is therefore NOT encrypted and nor is the query string.
The app then asks the user to enter a new password and this new password is sent via ajax to the back end, which is protected with SSL.
So my take on it is that it's worth setting up SSL for my single page application to assure security for the first consideration because the GET request is therefore NOT encrypted and nor is the query string and the token is sensitive information. However, it wouldn't be required if only the second consideration was taken into account since the connection between the single page app and the back end is done via SSL (because the single page app uses Ajax to communicate to an endpoint protected via SSL).
Am I right? Or completely sidetracked? Thanks!
Your intuition is correct. The only effective difference between your first and second scenario is that in (1) you are sending sensitive information (the token) to the front end server, and (2) you are sending sensitive information (password) to the back end server. So because you are sending sensitive information to both, they will both need to be secured by SSL.
If the front end server were not secured by SSL, here is a possible attack avenue:
Attacker MITMs the frontend server when the user sends the reset token in the query string, the attacker gains access to the reset token.
Before the real client can send a password reset request, the attacker sends the password reset request to the backend server.
The attacker sends the new password to the backend server. The password is reset to a password the attacker knows.
In no step does the attacker have to compromise the SSL of the backend server to pull off this attack on the frontend server. Of course the backend server will be receiving the password from the user, so it will need SSL too. In short, to protect against man-in-the-middle attacks you will need SSL for both of your servers.
I want to encrypt the query string values used in my MVC3 application. If i implement SSL certificate, whether all the parameters passed with url in encrypted form or not. The application is already completed, now its running appscan testing, so its very tough to encrypt and decrypt manually the query string.
As per answer given in this post
Yes, it is. But using GET for sensitive data is a bad idea for several reasons:
Mostly HTTP referrer leakage (an external image in the target page might leak the password1)
Password will be stored in server logs (which is obviously bad)
History caches in browsers
Therefore, even though Querystring is secured it's not recommended to transfer sensitive data over querystring.
I am working on a web page that uses a lot of AJAX to communicate with the server. The server, in turn, has an extensive REST/JSON API exposing the different operations called by the web client.
This web site is used by both anonymous and authenticated users. As you might expect, the web service calls issued by authenticated users require authentication, and are thus protected from unauthorized users or applications.
However, the web site has a lot of features that require no authentication, and some of these make use of anonymous web services. The only way I am using to prevent outsiders from calling this web services is by using a CSRF token. I know, the CSRF token is not very useful in this regard... with some time in hand, you can figure out how to consume the web services even if they use a CSRF token.
Of course, you can use a CAPTCHA to prevent applications or bots from autonomously using your web service. However, any human will be able to use it.
Sharing a secret key between client and server, on the other side, would be useless. This, because of the ability of any outsider to read it from the web page source code.
I would like to make these web services as difficult to invoke as posible to any 3rd party application. What would you do besides using the CSRF token? It sounds a little stupid, but hey, maybe it is stupid and I am just losing my time.
Note: given this application uses a browser and not an "executable" as the client, this question is irrelevant to the discussion. I cannot use a secret between server and client (not to my knowledge, at least)
I would take a few steps.
Force https on the site. Automatically redirect any incoming http requests to https ones (the RequireHttps attribute is handy for this)
Each page needs to (securely, hence the https) send a one-time use token to the client, to be used for the page. The script running on the client can hold this in the page memory. Any request coming back sends a hashed & salted response, along with the nonce salt. The server can repeat the steps with the saved token + salt and hash to confirm the request. (much like explunit's answer above)
(It's worth noting that the secure request from a client isn't being authenticated from a user account, merely a token sent with the full page.)
The definition for one-time could either be session or page load, depending on your security vs convenience preference. Tokens should be long and expired fairly quickly to frustrate attackers.
The SSL + Hash(token + nonce) should be enough for your needs.
This is interesting. Below is a crazy suggestion. Remember, your question is also equally crazy.
Your website, once opened through a browser, should generate a long polling connection (Comet programing). This will create a unique session between the browser and the server. When ur JS is making the ajax call, send some token (unique token every time) to the server through the long polling thread. Let the AJAX also send the same token. At the server, get the AJAX token and check whether you have a similar token in you long polling session. If yes, fulfill the request. Any coder can break this. But, it won't be easy. Chances are the freeboarders won't even see these second piece of comet code. You can implement the comet code in such a way it is not easy to detect or understand. When they call ur service, send a 'Service Unavailable' message. They will be confused. Also make the comet code https.
You can also check how long that long polling thread is open. If the session was just opened and you get a ajax call right away, you can assume it is a 3rd party call. It depends on ur website flow. If ur Ajax call happens after 1 second of page load, you can check for that pattern on server side.
Anyone coding for your public api, will have 1 to 2 secret checks that they wouldn't even know and even if they know, they might be discouraged by all the extra coding they have to do.
You might have an easier problem than the one described in the linked question since you don't need to distribute a binary to the users. Even if your app is open source, the HMAC/signature key (in the "Request Signatures" part of that answer) can be controlled by an environment/configuration setting.
To summarize:
The secret key is not actually sent between client and server. Rather, it's used to sign the requests
Be sure that the requests include some unique/random element (your CSRF key probably suffices) so that two requests for the same API data are not identical.
Sign the request with the secret key and append the signature to the request. You linked to a PHP question but not clear if what language you're using. In .Net I would use a HMAC class such as HMACSHA256.
On the API server-side use the same HMAC object to verify that the request was signed with the same secret key.
Maybe you could use counters to keep track of conversations. Only the Server and Clients will be able to predict the next iteration in a conversation. This way, I think, you can prevent third party applications to impersonate someone (Just an idea though).
At the beginning, they start talking at some iteration (i=0, for example).
Every time the client requests something, the counter is incremented by some number in both the server side and the client (i=i+some_number).
And, after a few minutes of no communication, they both know they have to reset the counter (i=0).
This is just an idea based on the concept of RSA and also placing Fraud Detection on your system. The Risk from Authorized users is minimal however they can attempt to make anonymous calls to your web-service too.
For UN-Authorised users : For each web-service call , generate a token say using RSA which changes after some time(can be configured say 30 min). This way prediction of code is minimized. I have not heard of RSA collision till now. Send this token back to the user for his browser session. For further security , we might want to attach a session id with RSA token. Since session ids are unique new anonymous calls would require new session id.
Calls can be tracked using Auditing mechanism. Also per-web service there can be a different RSA setup. How the Algorithm for Fraud Detection would work is a challenge by itself.
For Authorized Users :
Every user should be tracked by his IP Address using Header block. The RSA token principle can be applied.
The solution is very vague but worth considering.
I'm trying to make a web service secure.
It's not for a bank or anything of that sort, but the organization using it may lose some money if the service will be used by someone not authorized (it's hard to tell exactly how much..).
The purpose is not to allow unauthorized applications to use any method (other than "GetChallenge". for users authentication there is a different mechanism which checks for username and password. I actually combined the two, but they serve different purposes):
So here's what I do:
I send a (ASP.NET) session key (for everyone to read. ASP.NET's session Is 15 randomly generated bytes, it lives for 20 minutes unless prolonged, and ASP.NET will not receive any request without it).
In my SignIn method, apart from username and password (which anyone can acquire, since it's a part of a public site), I receive a third parameter - the session key hashed by md5 algorithm with 6 bytes as salt.
And only if the hash is correct (I'm hashing and comparing it on the server side) - I let the users sign in.
From then on in every method, I check if the user is signed in.
Added: The username and password are sent as clear text, and that's not a problem (not the one I'm addressing at least). The problem is for someone (other than the company we're working with) writing an application which uses my web service. The web service should only be used by an authorized application.
Also, the session id is sent back and forth with every request and response (as a part of ASP.NET session mechanism. That's how ASP.NET knows to "track" a session specific for a user). Sorry for not clarifying that from the first place.
(irrationally thought it was obvious).
How strong and effective is that security strategy?
Thanks.
Updated based on your edit and comment
It's pretty secure and is very similar to the approach used by Google, Facebook and others for their API keys. Except...
Session ID plain text potential issue
I would recommend against using Session ID as part of a security mechanism.
The one issue is with passing the session key in plain text across the network. There is potential that this could open up some Session hijack and other attacks.
From the Microsoft Docs:
The SessionID is sent between the server and the browser in clear text, either in a cookie or in the URL. As a result, an unwanted source could gain access to the session of another user by obtaining the SessionID value and including it in requests to the server. If you are storing private or sensitive information in session state, it is recommended that you use SSL to encrypt any communication between the browser and server that includes the SessionID.
As you are using the Session ID as part of your security mechanism I would say that is sensitive data.
One way to ensure someone doesn't get hold of your session key is to run your service on HTTPS. Personally I would avoid using the Session ID in this way and generating a non-related value instead.
Recommended change
Follow more closely the model used by Google and the like. Generate a new GUID for each application, store the GUID in a database on the server, pass the GUID in each request to your server from the client.
Benfits:
Identifies the client application uniquely, allowing you to track and manage usage per client nicely
Easily disable any client by removing the GUID from your data store
No sensitive data on the wire
I would still run the service on HTTPS as it's easy to setup and gives the added benefit of protecting any other data you send to your service.
The purpose of encryption is not to
allow unauthorized applications to use
any method
Wrong. The purpose of encryption it to prevent the understanding of data whilst either in transit or stored. It prevents data being 'useable' by those that do not have the means to decrypt.
What you are describing is something similar to a public/private key system. You're making your session key available to everyone. Then only after they've md5 with the correct salt (as per your server side comparison) you're then trusting that source.
You've got NO authentication here except for username and password. Also your data isn't encrypted during transit. I fail to see how this is at all secure.
I think you're best bet is to use an SSL certificate (so your web service is running over HTTPS) along with the username and password. If you want to be doubly secure you might want to go down the route of checking source IP ranges and login locations as an additional check. Perhaps a forced password change interval will help in the case that consumers are passing credentials to a third party + audit how the web service is actually being used.
As a side note if you want to hash something don't use MD5, its broken.
From a web services perspective the ideal way to use authentication or provide security to your service is something like this: Web Service Authentication (Token and MD5 Hashing to encrypt password).
The way you describe it, it does not seem secure at all.
What is the point of letting the SignIn method accept a hashed session key, if the session key is public ("for everyone to read")?
Plus: "in every method, I check if the user is signed in. " How do you check that?
A common (and reasonably secure) strategy would be to generate a (unique, sufficiently long and random) session ID server-side, and send it to the client after it has authenticated. Then check every client request and only accept it if it contains the session ID. To do this, either embed the ID into all links on every page, or set it as a cookie, depending on what's easier for you.
On logout, just delete the session ID on the server.
That way, no one can invoke any method without a valid session.