I am using CouchDB for my Data Layer in a Rails 3 application using CouchRest::Model hosted on Heroku.
I am requesting a List of Documents and returning them as JSON to my Browser and using jQuery Templates to represent that data.
Is there a way I could build the request on the server side, and return the request that would need to be called from the browser WITHOUT opening a huge security hole i.e. giving the browser access to the whole database?
Ideally it would be a one off token access to a specific query, Where the token would be generated on the server side, and CouchDB would take the token, and make sure it matches what the query should be, and give access to the results.
One way that comes to mind would be to generate a token Document and use a show function (http://guide.couchdb.org/draft/show.html) to return the results for that token Document's view results. Though I am not sure if that is possible.
Though another is to put a token on the Document itself and use a list function (http://guide.couchdb.org/draft/transforming.html)
Save that, any other ideas?
Thanks in Advance
Is there a way I could build the
request on the server side, and return
the request that would need to be
called from the browser WITHOUT
opening a huge security hole i.e.
giving the browser access to the whole
database?
Yes. One method is to create a rack app and mount it inside your rails app. You can have it receive requests from users' browsers at "/couch" and forward that request to your "real" couchdb url, returning couch's JSON response as-is or modifying it however you need.
You may also be able to use Couch's rewrite and virtual host features to control what Couch URLs the general public is able to reach. This probably will necessitate the use of list or show functions. http://blog.couchone.com/post/1602827844/of-rewrites-and-virtual-hosting-an-introduction
Ideally it would be a one off token access to a specific query, Where the token would be generated on the server side, and CouchDB would take the token, and make sure it matches what the query should be, and give access to the results.
You might use cookies for this since list and show functions can set and get cookie values on requests.
But you could also include a hash value as part of each request. Heroku's add-on API has a good example of how this works. https://addons.heroku.com/provider/resources/technical/build/sso
Notice that the API calls are invalid outside of a certain window of time, which may be exactly what you need.
I'm not sure I precisely understand your needs, but I hope I have been able to give you some helpful ideas.
Related
I have developed an app for Android/iOS which calculates a value based on the users input. If an event occurs, this calculated value will be sent to my Backend as normal HTTPS payload. My question is now, how can I make sure, that this value is really only calculated by the source code of my app? Is there a way to handle such a problem?
To make it clear: I want to avoid, that somebody is rooting his phone, extract the Auth-Token from the private storage of my app and sends a valid HTTPS-Payload to my Backend with fictitious payload, manually or by manipulating the source code.
From the view of the backend, it's difficult to evaluate the payload based on its values if it is valid or not.
Any suggestions appreciated!
----------EDIT-----------
For the sake of completeness: apart from the answers here, the following are also very interesting:
Where to keep static information securely in Android app?
How to secure an API REST for mobile app? (if sniffing requests gives you the "key")
You can’t trust data coming from the client. Period.
You should consider moving the calculation logic to the server and just sending the raw values needed to perform the calculation. You can easily get sub-second response times sending the data to the server, so the user won’t notice a lag.
If you need offline connectivity, then you’ll need to duplicate the business logic on both the client and the server.
Short of doing everything on the backend, you can't very easily.
I'd recommend some reading around CSRF (Plenty of articles floating around) as that's at least a good mitigation against bots outside of your app domain hitting your backend. The upshot is that your application requests a unique, random, identifier from your backend (which ideally would be tied to the user's auth token) before submitting any data. This data is then submitted with your app's data to perform the calculation on the backend. The backend would then check this against the random identifier it sent for that user earlier and if it doesn't match, then reject it with a 400 (Bad Request), or 404 if you're paranoid about information leakage.
Which is safer in term of security, sending parameters thru url or JSON object?
URL:
www.mywebsite.com/search.php?password=t45vye45vh
JSON object:
request.post(url, data);
The GET method requests a representation of the specified resource.
Requests using GET should only retrieve data and should have no other
effect.
Whenever user want to data from server using only basic details like userId or some other id then use get request.
POST submits data to be processed (e.g., from an HTML form) to the
identified resource. The data is included in the body of the request.
This may result in the creation of a new resource or the updates of
existing resources or both.
Post method generally used for form or passing more number of data to server. Whenever something needs to store on server, post request is used. Eg. for registration, login, file upload, making new record etc.
It depends what you are trying to secure against. For information assurance and maintaining an accurate audit history the URL is easier to capture in logs than the body of a request. It is also simpler to parse in a WAF.
To protect against abuse of this information then you might want to make it less obvious. Anyone reading the standard webserver log that uses your first example will be able to see passwords. Your browser will also retain this value in its history and users can create bookmarks containing passwords - neither provides a secure method of storage.
For anything sensitive use POST.
With HTTPS enabled, it is true that query string parameters are encrypted and cannot easily be sniffed. However, GET requests are stored in browser history, and proxy and server logs by default. They can also be leaked in the referer header.
POST requests are unlikely to be logged, and do not have the referer issue.
wkhtmltopdf allows to make a screenshot of a browser view with a webkit browser.
I have a Symfony 1.4 application that requires login, which I would like to use wkhtmltopdf to create a "print this page" function.
How can I securely facilitate this. I'm thinking of creating a one-off token on each screen for the print button that allows wkhtmltopdf to login without using the password of the user.
Any suggestions for how to structure this?
We'vbe come to the conclusion to use the built in "keep me logged in" functionality for this problem.
Would you consider a different printing framework ?
What about jquery plugin (e.g. https://github.com/ianoxley/jqueryprintpage#readme) ?
That way you won't have to allow access to the restricted area from outside the session.
If you still want to use wkhtmltopdf, you can easily create an action that receives a url and a user_id and creates a unique token, I might save this token in your DB or in a Key-Value cache (depends what is your system architecture). I wouldn't create the unique token in advance, I think its better creating it on demand (When your user is asking a print).
You have couple of options in order to enable printing in secured actions,
1) Create a custom security filter. In the filter, in addition to authenticated request, you have to allow requests that contain "token" parameter with right combination of url and user
2) Change the action to unsecured. If you don't want the change the security filter, you would have to change each action to "unsecured" and create a function that verifies if either the request is authenticated or it has a proper token parameter.
It would be smart to remove each token after you used it once to make it even harder to guess a token.
In addition you might want to create a periodic worker that clears old tokens that were never in use.
Even though you already decided on an approach, I would still like to add one more alternate option that might help others viewing this issue.
Another alternate route might be to grab the current source of the page being viewed and post that into your printer backend using something like
$.post("/printer", document.documentElement.outerHTML);
This way you can also preprocess the HTML in an easy way. Your backed could first store the HTML and then parse it to for example convert images or perhaps remove some parts of the page that will not be used when printing.
I have a url to a search page (e.g. http://x.y.z/search?initialQuery=test). It isn't a webservice endpoint, its just a basic url (which goes through a Spring controller). There is no security around accessing page, you can enter the link in a browser and it will render results.
What I want is to find a way to prevent other sites from submitting requests to this url, unless they are specifically allowed.
I build a filter which would intercept all request to this page, and perform some validation. If validation failed then they would be redirected to another page.
The problem is what validation to perform... I tried using the referer field to see if the request was coming from an "allowed" site but I know the referer field isn't always populated and can easily be faked.
Is there a way to achieve this?
We also have IHS so if there is something that can be done in there either that would be great.
I'd suggest implementing some kind of system to allow users to log in if you really want to protect a page from being accessed.
You could try to detect the IP address of the incoming request, but I'd imaging that this can be spoofed quite easily.
Realistically, pages that are public are open to any kind of interrogation to the limits that you set. Perhaps limiting the data that the page returns is a more practical option?
This is the reason that website's like Facebook and Twitter implement oAuth to prevent resources from being accessed by unauthorised users.
How about you only run the result if the referring page has passed along a POST variable called "token" or something which has been set to a value that you give each app that's going to hit the search page. If you get a request for that page with a query string, but not POST value for "token", then you know its an unauthorized request and can handle it accordingly.
If you know the IPs of sites which can contact your service, you can put Apache as a proxy and use access control to permit/deny access to specific directories/urls.
I assume that you want to avoid having your site "scraped" by bots, but do want to allow humans to access your search page.
This is a fairly common requirement (google "anti scraping"). In ascending order of robustness (but descending order of user-friendliness):
block requests based on the HTTP headers (IP address, user agent, referrer).
implement some kind of CAPTCHA system
require users to log in before accessing the search URL
You may be able to buy some off-the-shelf wizardry that (claims to) do it all for you, but if your data is valuable enough, those who want it will hire mechanical turks to get it...
make a certification security.
u can make self signed certification using openssl or java keytool
and u will have to send a copy of certificate to ur client.
If this client will not have this certificate, It will not be able to call ur service.
And to make certificate enable in ur web container.I dont know bout other containers but
in Apache tomcat, u can do it in connector tag of ur server.xml
I don't know if the title is clear enough, anyway what I need to do is quite simple: I have some content you can access by an API call on my server; this content is user-related so when you request access to it, you must first wait for the owner to authorize you. Since this content will be probably embedded into blog articles or form posts I want it to be accessible only from the URL the user authorized to.
The only way that came to my mind is to check in some secure way where the request is coming from: the problem with this approach is that anybody could create a fake request, using a valid URL but coming from a non-authorized URL actually.
I'm looking for a way to solve this problem, even if this doesn't involve checking the actual URL but using some other approach or whatever. Feel free to ask any questions if this is not clear enough.
With Sessions:
If you generate a secure token, most languages have libraries to do such a thing, you will have to persist it probably in a session on your server. When you render the page which will access the other content you can add that token to the link/form post/ajax request on the page you wish to be able to access it from.
You would then match that token against the value in the user session if the token doesn't match you return an error of some sort. This solution relies on the security of your session.
Without Sessions:
If you don't have sessions to get around server persistance, you can use a trick that amazon s3 uses for security. You would create something like a json string which gives authorization for the next 30 seconds, 5 minutes, whatever is appropriate. It would need to include a timestamp so that the value changes. You would use a secret key on your sever that you combine with the JSON string to create a hash value.
Your request would have to include the JSON string as one request parameter. You would need to base64 encode it or some other means so that you don't run into special characters not allowed over http. The second parameter would be the output of your hash operation.
When you get the request you would decode the JSON string so it was exactly the same as before and hash it with your secret key. If that value matches the one sent with the request it means those are the two values you sent to the page that ultimately requested the content.
Warnings:
You need to make sure you're using up to date algorithms and properly audited security libraries to do this stuff, do not try to write your own. There may be other ways around this depending on what context this ultimately ends up in but I think it should be relatively secure. Also I'm not a security expert I would consult one if you're dealing with very sensitive information.