I run a landscaping company and have multiple crews. I want to provide each one with a custom URL (like mysite.com/xxxx-xxxx-xxxx) that shows their daily schedule. Going to the page will list the name, address and phone number of 5-10 customers for the day.
Is it safe/wise to use a UUID in a URL for semi-private data?
Depends on how safe you want it to be.
Are the UUIDs used for anything else? If not, they are fine for creating random URLs.
But, browser history would allow anyone using the same machine to find the URLs. Also, unless using https, a network sniffer could easily see the requested URLs and go to the same page.
Another concern is spider bots. Make sure nothing links to those pages, use a robots.txt to prevent indexing the site, but you still might find that some of the pages show up on search engines. It might be better to have the UUID set in a cookie and check that for determining which employee it is, lest your semi-private pages start showing up on google.
Whether or not that schema would work for you, depends on your threat model (as well as some implementation details). Without a concrete threat model, it is not possible to give a definitive answer to your question.
I can, however, give you some ideas about potential issues with the solution, so you can determine if they are relevant for your application. This is not a complete list.
On the implementation side of things:
Not all UUID generators are created equal. Ideally, you want to use a generator based on a cryptographically secure RNG, providing an UUID where every byte is chosen at random.
Using the UUID for a database lookup or similar operation is not necessarily a constant-time operation (and thus there might be side-channel attacks unless you implement the lookup by yourself)
Make sure your URI does not leak via referrer
Some tools attempt to detect 'secret' URLs to protect them from history synchronization or other automatic features. Your schema will most likely not be detected as 'secret'. It might be better to artificially lengthen your URI and to move your UUID into a query parameter.
You can further reduce attack surface with the usual methods (rate limiting, server hardening, etc.)
On the conceptual side of things:
A single identifier for both identification and authentication is not necessarily a bad thing. However, in most cases there is a need for an identification-only identifier – you must not use the 'secret' UUID in those scenarios
If a 'crew' consists of multiple people: you cannot revoke access for a single crew member
Some software (antivirus, browser, etc.) treats information in URLs as public information, and might upload them without user interaction
Related
I work for a bank and security is a major concern. We are currently using a cname on Adobe's collection servers (e.g. stats.bank.com) in order to have Adobe serve first party cookies on the bank.com domain. Our security council now says we shouldn't provide Adobe with a new SSL cert for stats.bank.com because it is too risky and if stats.bank.com is compromised and someone attacks our customers then we our liable due to it being our brand and all the cookie data is exposed as well as leaving customers open to malware attacks. So we have the following options:
Bring reporting in-house
Set up a filtering proxy operating as “stats.bank.com” that front-ends the relevant Adobe service
Go back to Adobe's 3rd Party solution 2o7.net namespace
Use a different 3rd party namespace on adobe's servers (e.g. stats.bk.com)
Here are our thoughts:
1) Too expensive
2) We thought it was a good solution but then the cost came up. It seems like it would be very costly to build that type of infrastructure due to the volume of calls.
3) Adobe's 3rd party namespace blocked too much.
4) Seems to maybe be a solution but still concerned about 3rd party being blocked.
I was wondering if anyone has had to deal with these type of security concerns and what the solution was. Also what are the drawbacks of solution #4 in particular?
There is no personally identifiable or personal information at all in Adobe's tracking cookie.
Before I say anything else, based on what you have said, let me just say that I think your security council is either misinformed about Adobe's tracking cookie or else blowing things unrealistically out of proportion.
The visitor id (s_vi) cookie is just that: a cookie that contains a visitor id value. Here is an example of what the cookie value looks like:
[CS]v1|2A933F6C05079103-6000110EA000D3F3[CE]
The value has nothing to do with a visitor's personal information or data or anything like that. It is a randomly generated value that sticks to the visitor for as long as the cookie persists.
Cookies that are created for any custom coding you do are NOT the same thing
See, this is where I think some people may be confused. Here is a common scenario to explain: member id tracking. A visitor when they first come to your site is anonymous. They login to your site and now your site knows who they are.
From a tracking perspective, it is common to have a prop and/or eVar that reflects this. So on pages/hits where you don't know the visitor, you wouldn't pop anything, or maybe you'd pop some default "anonymous" or "unknown" or "logged out" value. Then when the visitor logs in, you pop the prop/eVar with a value that your site recognizes as a member or account id.
Maybe this id is their email address. Maybe it's a randomly generated value. Maybe it's a username. Point is, it's something to uniquely identify the visitor within your own site's system.
So let's say you write code where upon login, you pop prop1 with the value and then you decide to make use of Adobe's getAndPersist plugin. This plugin basically takes a value and puts it into a cookie and then retrieves the value each time the plugin is called. The idea here is that you only have to do the work to come up with the value from your end one time and then Omniture will persist it from there. This is particularly useful for when you want a value to pop for each page/hit but may not have easy access to replicate or scope the logic to all areas of your site, particularly across subdomains.
So now you have a cookie set by Adobe Analytics code from this. This has nothing to do with the s_vi cookie at all.
Firstly, it is something you explicitly set, even if it is just to get the ball rolling. Secondly, the value is not stored in the s_vi cookie; it is stored in a separate, 1st party cookie.
Even if you have FPC tracking, it is still set in a separate cookie. The actual cookie name depends on what plugin you are using (or using Adobe's s.c_w cookie write function yourself), and also whether or not you are using the combined cookie plugin (in which case it will be put in s_sess or s_pers, depending on what you set the expiration to be)
Now.. if you do have FPC implemented, you can obviously overwrite that cookie with your own value. And you can obviously make that value whatever you want it to be, including something personal to the visitor. But that's not Adobe's doing; that's your doing.
The overall point here is that whether you make the visitor tracking 1st party or 3rd party, that's a completely separate cookie that has nothing to do with personal data.
You may have custom coding that contains personal data and you may put that data into cookies, even using Adobe Analytics functions, but that is not the same thing. It will always be first party cookies (impossible for js to write 3rd party cookies), and the cookies will always be separate.
Nonetheless, the s_vi visitor id may be used to indirectly get personal data
I'm sure the next thing heard will be something along the lines of "But it doesn't matter, it's a unique id for the visitor, and it's in Adobe, and so is this other data, and you can use the visitor id to find the data within Adobe!"
And this is true. However...
Firstly, in order for there be personally identifiable data to be found within Adobe Analytics, you have to explicitly put it there. For example, you have to set stuff like:
s.prop1='jon doe'; // name
s.prop2='4321 1111 1111 1111'; // credit card #
s.prop3='04/2020'; // exp date
s.prop4='123'; // security number
I don't think I should have to tell you that this is a supremely bad idea, but point is, this isn't Adobe collecting that info, it is you doing it. And it's not in the s_vi visitor id cookie, nor can it ever be (again, unless you have fpc imp and decide to explicitly overwrite the cookie with those values..).
So that data, along with the visitor id, goes off to Adobe servers. So there's the next road block: getting access to the data within Adobe. The bad guy would have to have a Adobe Analytics user account under your company, and it would have to have proper permissions to gain access to that data.
And even then, Adobe doesn't actually expose the visitor id value in the reports. So in order to get the data associated with a certain visitor id, you need access to data warehouse, or to be listed as a supported user and request raw hit logs from ClientCare.
I guess the overall point here is that all by itself, that visitor id isn't really the dangerous thing. It's not the personal data, and being able to make use of it to find specific data associated with it would involve acts of extreme foolishness about storing personal data on Adobe servers in the first place, as well as gaining access to said servers/interfaces.
All that aside..
Okay, so maybe you don't care about all of that stuff above. Or maybe none of that convinced your security council to budge. You're moving away from Adobe FPC imp and that's all there is to it. So let's talk about the options you listed and your concerns about them.
Bring reporting in-house
You said this is "too expensive." You know, I gotta be honest here.. this is a bit laughable, coming from a bank! But seriously..
Perhaps you thought it too expensive from a building-from-the-ground-up-from scratch perspective? If this is the case, have you considered options for ones that have already been built, that you can put on your own server and customize or build off of from there?
Webtrends offers this. Frankly, I loathe Webtrends as a tracking solution, but it does offer ability to put it on your own server (last I heard, anyways). Also, Piwik is a really good open source solution.
Filtering proxy
I'm not quite sure what you mean by this. This sounds a lot like FPC tracking.. except having a means to scrub all requests of personal data before it goes to Adobe? Well if that is the case, I'd go back to the point about sending personal data to Adobe in the first place. But okay, maybe you aren't doing that, but want to have an extra measure of precaution just in case; fair enough.
So maybe you setup a service on your end that sends all requests to stats.bank.com and it scrubs stuff and maybe even has a mapping of values (like visitor id). In principle, this isn't really a complex script, so again I have to wonder why cost is an issue, especially coming from a bank.. but whatever..
Sticking with Adobe's 3rd party cookie implementation
If you want to go back to 3rd party cookie tracking using a domain owned by Adobe, instead of using the default 2o7.net domain, I suggest you consider their new(er) 3rd party cookie implementation for Regional Data Collection.
Rolling your own 3rd party cookie implementation
As far as I am aware, Adobe does not offer any kind of service involving you specifying a domain name for them to purchase/own and collect data from as a 3rd party implementation.
The closest service to this is the first party cookie tracking. So, you if you have www.bank.com, normally you'd specify something like stats.bank.com (something on the root domain) and that's FPC tracking.
However, you can tell Adobe to use for example stats.someotherdomain.com (assuming you own and control it) and they can implement FPC tracking for that domain. Then, when you implement tracking on www.bank.com, that effectively becomes 3rd party cookie tracking.
The caveat though is that you still own that domain, so I can only assume that on some level, you will still be liable for it (I'm not a lawyer). However, maybe this will be enough to appease your security council, worth bringing it up to them.
I add that, under the Adobe General Terms of Service, "customer agrees not to collect, process, or store any Sensitive Personal Data using the on-demand or managed services." Hence, if you are collecting any data that can be traced back to an individual -- e.g., email address or phone number -- you are violating the TOS. Therefore, the response to security concerns can be, "Exposing customer PII is a violation of our terms of service and so we don't do it."
I have an S3 bucket containing objects that I want to share with users of a website. I know I can use something like Query String Authentication to provide secure access to the objects, but what if I instead make each object publicly-readable yet "hidden" behind a complex key (i.e. URL) containing a cryptographically-strong random number? If the containing bucket disallows listing of objects, there wouldn't be a way to guess or discover the URLs, correct? Or is there some security hole I'm overlooking?
Side note: my first thought was to use UUIDs in the keys, but I read that they can apparently be predicted, given a few previous instances. That said, I don't have an understanding of how easily that can be done. If it's non-trivial, I probably wouldn't worry too much about using them instead of a strong random number...
The problem is if the once shared URL gets into the hands of another user (say via sharing). If you ensure the URL is kept sufficiently secret, it is ok with this approach (say you return the URL to a user via https, and this user dont share it).
Any loophole here will cause a security hole - and here is where the query string based signature scheme is helpful, since the signatures are made to expire after a fixed time and so any re-sharing wont also harm you.
You can use UUIDs (ensure they dont end up duplicating, by regenerating another one if the new one collides). They are probably as difficult (or more) to guess as any other 8-letter password.
The standard way to do what you want is to generate pre-signed URLs for each of the objects you want to share. If you make them with a short lifetime, then they cannot be shared outside that time period. All of the AWS-provided SDKs have support for this feature.
I see many sites that store cookie data as garbled text, for example: a cookie named aASFaewqWDRE#fr with an equally unreadable value. I've always kept my cookies human readable, but never keep critical data within them. For example, I'd make a cookie called favorite_items with a string like so 14,73,7, each number being a reference to something like a product.
If my cookie were to be stolen, the attacker would immediately know that this user had items 14, 73, and 7 in their favorites. This doesn't compromise the users account in any way, as far as I know (assuming that my site is well built and an account can't be accessed with solely this information).
Are there other security concerns with this practice that I haven't thought of?
How do I really know that this is question is really from the legitimate user Brian? How do I know that it's not someone trying to trip people up? It would be in the general interest of security (for whatever reason) to encode ('garble') your data - simple because you do not know who or what is monitoring your data. Consider an account with amazon or a major retailer where a customer's credit card information is on file. If the data being monitored, it would be very simple for a potential hacker/malicious program to extract the information he needs. He can either directly get credit card details or he simply just has to acquire their username/password combination. Now when this comes to banks, it becomes extremely important.
But even outside of financial transactions, it is good to encrypt your details to prevent you from being spammed and or to prevent the illegal use of your account - imagine your boss getting an email from you with stuff that he might not like. The list is endless. The bottom line really is that there are a lot of messed up people out there and if you can do something to get that extra level of protection for not much additional cost, then why not?
What are the dangers of storing plaintext data in cookies?
The "danger" is obvious. The user (and potentially others!) can read the information, and potentially "fiddle" with it.
Whether it matters depends what the information is, how you handle the cookies and what you are worried about. For example ...
If you are using the cookie content for implementing your site security / user access control, then passing the information it the clear could give the user extra some knowledge to subvert your scheme ... depending on how you implemented it.
If you are using the cookie content for information that the user might consider as sensitive, then passing the "clear" cookies over an HTTP connection makes it vulnerable to some bad guy who can snoop the packets. (Actually, given the HTTPS is "not really as secure as we were lead to believe" ... this probably applies across the board!)
If you are using the cookies for tracking the user ... or something else that the user would probably not like you doing ... well, go figure!
But seriously, your question strongly suggests that you need to learn a lot more about how to address security and privacy concerns in website / webtool implementation.
For a start, simply "garbling" the information is insufficient. Any light-weight "garbling" scheme can easily be reverse engineered. If you care about security / privacy, the information should be encrypted using strong encryption with properly handled keys ... or not stored in cookies in the first place. (Read up on schemes for storing session-related information on the server side.)
I'm currently developing a web application that has one feature while allows input from anonymous users (No authorization required). I realize that this may prove to have security risks such as repeated arbitrary inputs (ex. spam), or users posting malicious content. So to remedy this I'm trying to create a sort of system that keeps track of what each anonymous user has posted.
So far all I can think of is tracking by IP, but it seems as though it may not be viable due to dynamic IPs, are there any other solutions for anonymous user tracking?
I would recommend requiring them to answer a captcha before posting, or after an unusual number of posts from a single ip address.
"A CAPTCHA is a program that protects websites against bots by generating and grading tests >that humans can pass but current computer programs cannot. For example, humans can read >distorted text as the one shown below, but current computer programs can't"
That way the spammers are actual humans. That will slow the firehose to a level where you can weed out any that does get through.
http://www.captcha.net/
There's two main ways: clientside and serverside. Tracking IP is all that I can think of serverside; clientside there's more accurate options, but they are all under user's control, and he can reanonymise himself (it's his machine, after all): cookies and storage come to mind.
Drop a cookie with an ID on it. Sure, cookies can be deleted, but this at least gives you something.
My suggestion is:
Use cookies for tracking of user identity. As you yourself have said, due to dynamic IP addresses, you can't reliably use them for tracking user identity.
To detect and curb spam, use IP + user browser agent combination.
Our team have built a web application using Ruby on Rails. It currently doesn't restrict users from making excessive login requests. We want to ignore a user's login requests for a while after she made several failed attempts mainly for the purpose of defending automated robots.
Here are my questions:
How to write a program or script that can make excessive requests to our website? I need it because it will help me to test our web application.
How to restrict a user who made some unsuccessful login attempts within a period? Does Ruby on Rails have built-in solutions for identifying a requester and tracking whether she made any recent requests? If not, is there a general way to identify a requester (not specific to Ruby on Rails) and keep track of the requester's activities? Can I identify a user by ip address or cookies or some other information I can gather from her machine? We also hope that we can distinguish normal users (who make infrequent requests) from automatic robots (who make requests frequently).
Thanks!
One trick I've seen is having form fields included on the login form that through css hacks make them invisible to the user.
Automated systems/bots will still see these fields and may attempt to fill them with data. If you see any data in that field you immediately know its not a legit user and ignore the request.
This is not a complete security solution but one trick that you can add to the arsenal.
In regards to #1, there are many automation tools out there that can simulate large-volume posting to a given url. Depending on your platform, something as simple as wget might suffice; or something as complex (relatively speaking) a script that asks a UserAgent to post a given request multiple times in succession (again, depending on platform, this can be simple; also depending on language of choice for task 1).
In regards to #2, considering first the lesser issue of someone just firing multiple attempts manually. Such instances usually share a session (that being the actual webserver session); you should be able to track failed logins based on these session IDs ang force an early failure if the volume of failed attempts breaks some threshold. I don't know of any plugins or gems that do this specifically, but even if there is not one, it should be simple enough to create a solution.
If session ID does not work, then a combination of IP and UserAgent is also a pretty safe means, although individuals who use a proxy may find themselves blocked unfairly by such a practice (whether that is an issue or not depends largely on your business needs).
If the attacker is malicious, you may need to look at using firewall rules to block their access, as they are likely going to: a) use a proxy (so IP rotation occurs), b) not use cookies during probing, and c) not play nice with UserAgent strings.
RoR provides means for testing your applications as described in A Guide to Testing Rails Applications. Simple solution is to write such a test containing a loop sending 10 (or whatever value you define as excessive) login request. The framework provides means for sending HTTP requests or fake them
Not many people will abuse your login system, so just remembering IP addresses of failed logins (for an hour or any period your think is sufficient) would be sufficient and not too much data to store. Unless some hacker has access to a great many amount of IP addresses... But in such situations you'd need more/serious security measurements I guess.