Over here in symfony's tutorial, it says:
Hide all ids
Another good practice in symfony
actions is to avoid as much as
possible to pass primary keys as
request parameters. This is because
our primary keys are mainly
auto-incremental, and this gives
hackers too much information about the
records of the database.
Why is that so? And does it apply to all web apps?
Exposing keys is a potential internal direct object reference risk. In essence, it's saying that if keys conform to a predictable pattern, they may be used against you in an attack. Of course other layers of security should prevent his (proper authorisation, in particular), but it's one more little layer of security. The concept is relevant to all apps which expose internal keys.
See OWASP Top 10 for .NET developers part 4: Insecure direct object reference for more info.
Related
We would like to add additional layer of security to our database and we want to make sure that even if DB files will leak to public - noone will be able to reach the actual data inside it.
Additionaly we want to make sure that even if the encryption key will leak it will only allow to decrypt one or few rows, while others will still be inaccessible.
What are the best practices for doing that?
If it's important - we are using rails(5.1) + postgres(9.6) and our database is running in AWS RDS.
From the way your question is asked, you are simply not ready for this and heading for a world of pain if you try to tackle it. Again, applying a lot of inference, that you seem confused about where to start with this makes me think there are a lot of other security measures you have not put in place. Measures which might give you greater benefits for less cost and risk.
There are several different conventional models for applying encryption to data at rest. What you ask as additional requirements will require a tremendously complex application tier managing many, many encryption keys. Most experts would quake at the prospect of trying to implement this. Where are you going to store all the keys? What you've not asked is also very telling - what impact do you think opaque data has on query performance?
Yes, if your application sits in AWS there are different potential risks of direct file access than on a dedicated device - but you deal with that by using filesystem or block level encryption or the native capabilities of your DBMS (understanding what impact the latter has on your data access).
Can UUID on database level be used as a security measure instead of a true rights control?
Consider a web application where all servlets implements "normal" access control by having a session id connected to the user calling it (through the web client). All users are therefore authenticated.
The next level of security needed is if a authenticated user actually "owns" the data being changed. In a web application this could for example be editing some text in a form. The client makes sure a user, by accident, doesn’t do something wrong (JavaScript). The issue is of course is that any number of network tools could easily repeat the call made by the browser and, by only changing the ID, edit a different row in the database table behind the servlet that the user does not "own".
My question is if it would be sufficient to use UUID's as keys in the database table and thereby making it practically impossible to guess a valid ID (https://en.wikipedia.org/wiki/Universally_unique_identifier#Random_UUID_probability_of_duplicates)? As far as I know similar approaches is used in Google Photos (http://www.theverge.com/2015/6/23/8830977/google-photos-security-public-url-privacy-protected) but I'm not sure it is 100% comparable.
Another option is off cause to have every servlet verify that the user is only performing an action on its own data, but in a big application with 200+ servlets and 50-100 tables this could be a very cumbersome task where mistakes could easily happen. In my mind this weakens the security far more, but I'm not sure if that is true.
I'm leaning towards the UUID solution, but I'm also curious if there are other obvious approaches to this problem that I ought to consider.
Update:
I should probably have clarified that my plan would be to use UUIDv4 which is supposed to be random. I know that entropy comes in to play here in regards to how random the UUID's actually are, but as far as I have read then Java (which is the selected platform/language) uses SecureRandom which is supposed to be "cryptographically strong" (link).
And in that case wiki states (link):
In other words, only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%.
Using UUIDs in this manner has two major issues:
If there are no additional authentication methods, any attacker could simply guess UUIDs until they find one belonging to someone else. Google Photos doesn't need to worry about this as much, because they only use UUIDs to obfuscate publicly-shared photo views; you still need to authenticate to modify the photos. This is especially dangerous because:
UUIDs are intended to be unique, not random. There are likely to be predictable patterns in your UUIDs that an attacker would be able to observe and take advantage of. In addition, even without a clear pattern, the number of UUIDs an attacker needs to test to find a valid one swiftly decreases as your userbase grows.
I will always recommend using secure, continuously-checked authentication. However, if you have a fairly small userbase, and you are only using this to obfuscate public data access, then using UUIDs in this manner might be alright. Even then, you should be using actual random strings, and not UUIDs.
Another option is off cause to have every servlet verify that the user
is only performing an action on its own data, but in a big application
with 200+ servlets and 50-100 tables this could be a very cumbersome
task where mistakes could easily happen. In my mind this weakens the
security far more, but I'm not sure if that is true.
With a large legacy application adding in security later is always a complex task. And you're right - the more complicated an application, the harder it is to verify security. Complexity is the main enemy of security.
However, this is the best way to go rather than by trying to obscure insecure direct object reference problems.
If you are using these UUIDs in the query string then this information within URLs may be logged in various locations, including the user's browser, the web server, and any forward or reverse proxy servers between the two endpoints. URLs may also be displayed on-screen, bookmarked or emailed around by users. They may be disclosed to third parties via the Referer header when any off-site links are followed. Placing direct object references into the URL increases the risk that they will be captured by an attacker. An existing user of the application that then has their access revoked to certain bits of data - they will still be able to access this data by using a previously bookmarked URL (or by using their browser history). Even where the ID is passed outside of the URL mechanism, a local attacker that knows (or has figured out) how your system works could have purposely saved IDs just for the occasion.
As said by other answers, GUIDs/UUIDs are not meant to be unguessable, they are just meant to be unique. Granted, the Java implementation does actually generate cryptographically secure random numbers. However, what if this implementation changes in future releases, or what if your system is ported elsewhere where this functionality is different? If you're going to do this, you might as well generate your own cryptographically secure random numbers using your own implementation to use as identifiers. If you have 128bits of entropy in your identifiers, it is completely infeasible for anyone ever to guess them (even if they had all of the world's computing power).
However, for the above reasons I recommend you implement access checks instead.
You are trying to bypass authorisation controls by hoping that the key is unguessable. This is a security no-no. Depending on whom you ask, they may refer to it as an insecure direct object reference or a violation of the complete mediation principle.
As noted by F. Stephen Q, your assumption that UUIDs are unique does not imply that they are not predictable. The threat here is that if a user knows a few UUIDs, say his own, does that allow him to predict other peoples' UUIDs? This is a very real threat, see: Cautionary note: UUIDs generally do not meet security requirements. Especially note what the UUID RFC says:
Do not assume that UUIDs are hard to guess; they should not be used as
security capabilities (identifiers whose mere possession grants
access), for example.
You can use UUIDs for keys, but you still need to do authorisation checks. When a user wants to access his data, the database should identify the owner of the data, and the server logic needs to enforce that the current user is the same as the database claims the owner is.
I'm currently in the process of building a browser helper object.
One of the things the BHO has to do is to make cross-site requests that bypass the cross-domain policy.
For this, I'm exposing a __MyBHONameSpace.Request method that uses WebClient internally.
However, it has occurred to me that anyone that is using my BHO now has a CSRF vulnerability everywhere as a smart attacker can now make arbitrary requests from my clients' computers.
Is there any clever way to mitigate this?
The only way to fully protect against such attacks is to separate the execution context of the page's JavaScript and your extension's JavaScript code.
When I researched this issue, I found that Internet Explorer does provide a way to achieve creation of such context, namely via IActiveScript. I have not implemented this solution though, for the following reasons:
Lack of documentation / examples that combines IActiveScript with BHOs.
Lack of certainty about the future (e.g. https://stackoverflow.com/a/17581825).
Possible performance implications (IE is not known for its superb performance, how would two instances of a JavaScript engines for each page affect the browsing speed?).
Cost of maintenance: I already had an existing solution which was working well, based on very reasonable assumptions. Because I'm not certain whether the alternative method (using IActiveScript) would be bugfree and future-proof (see 2), I decided to drop the idea.
What I have done instead is:
Accept that very determined attackers will be able to access (part of) my extension's functionality.
#Benjamin asked whether access to a persistent storage API would pose a threat to the user's privacy. I consider this risk to be acceptable, because a storage quota is enforced, and all stored data is validated before it's used, and it's not giving an attacker any more tools to attack the user. If an attacker wants to track the user via persistent storage, they can just use localStorage on some domain, and communicate with this domain via an <iframe> using the postMessage API. This method works across all browsers, not just IE with my BHO installed, so it is unlikely that any attacker dedicates time at reverse-engineering my BHO in order to use the API, when there's a method that already works in all modern browsers (IE8+).
Restrict the functionality of the extension:
The extension should only be activated on pages where it needs to be activated. This greatly reduces the attack surface, because it's more difficult for an attacker to run code on https://trusted.example.com and trick the user into visiting https://trusted.example.com.
Create and enforce whitelisted URLs for cross-domain access at extension level (in native code (e.g. C++) inside the BHO).
For sensitive APIs, limit its exposure to a very small set of trusted URLs (again, not in JavaScript, but in native code).
The part of the extension that handles the cross-domain functionality does not share any state with Internet Explorer. Cookies and authorization headers are stripped from the request and response. So, even if an attacker manages to get access to my API, they cannot impersonate the user at some other website, because of missing session information.
This does not protect against sites who use the IP of the requestor for authentication (such as intranet sites or routers), but this attack vector is already covered by a correct implemention a whitelist (see step 2).
"Enforce in native code" does not mean "hard-code in native code". You can still serve updates that include metadata and the JavaScript code. MSVC++ (2010) supports ECMAScript-style regular expressions <regex>, which makes implementing a regex-based whitelist quite easy.
If you want to go ahead and use IActiveScript, you can find sample code in the source code of ceee, Gears (both discontinued) or any other project that attempts to enhance the scripting environment of IE.
We're trying to implement the Gatekeeper Design pattern as recommended in Microsoft Security Best Practices for Azure, but I;m having some trouble determining how to do that.
To give some background on the project, we're taking an already developed website using the traditional layered approach (presentation, business, data, etc.) and converting it over to use Azure. The client would like some added security built around this process since it will now be in the cloud.
The initial suggestion to handle this was to use Queues and have worker roles process requests entered into the queue. Some of the concerns we've come across are how to properly serialize the objects and include what methods we need run on that object as well as the latency inherent in such an approach.
We've also looked setting up some WCF services in the Worker Role, but I'm having a little trouble wrapping my head around how exactly to handle this. (In addition to this being my first Azure project, this would also be my first attempt at WCF.) We'd run into the same issue with object serialization here.
Another thought was to set up some web services in another web role, but that seems to open the same security issue since we won't be able to perform IP-based security on the request.
I've searched and searched but haven't really found any samples that do what we're trying to do (or I didn't recognize them as doing so). Can anyone provide some guidance with code samples? Thanks.
Please do not take this the wrong way, but it sounds like you are in danger of over-engineering a solution based on the "requirement" that 'the client would like some added security'. The gatekeeper pattern that is described on page 13 of the Security Best Practices For Developing Windows Azure Applications document is a very big gun which you should only fire at large targets, i.e., scenarios where you actually need hardened applications storing highly sensitive data. Building something like this will potentially cost a lot of time & performance, so make sure you weigh pro's & con's thoroughly.
Have you considered leveraging SQL Azure firewall as an additional (and possibly acceptable) security measure? You can specify access on an IP address level and even configure it programmatically through stored procedures. You can block all external access to your database, making your Azure application (web/worker roles) the only "client" that is allowed to gain access.
To answer one of your questions specifically, you can secure access to a WCF service using X.509 certificates and implement message security; if you also need an SSL connection to protect data in transit you would need to use both message and transport security. It's not the simplest thing on earth, but it's possible. You can make it so only the servers that have the correct certificate can make the WCF request. Take a look at this thread for more details and a few more pointers: http://social.msdn.microsoft.com/Forums/en-US/windowsazuresecurity/thread/1f77046b-82a1-48c4-bb0d-23993027932a
Also, WCF makes it easy to exchange objects as long as you mark them Serializable. So making WCF calls would dramatically simplify how you exchange objects back and forth with your client(s).
I have a webapp that requires security beyond that of a normal web application. When any user visits the domain name, they are presented with two text fields, a username field, and a password field. If they enter a valid user/pass, they get access to the web application. Standard stuff.
However, I'm looking for additional security beyond this standard setup. Ideally it would be a software solution, but I'm also open for hardware solution as well (hardware=key fobs), or even procedural changes (one time use passwords on a password pad for example).
The webapp is unique in that we know all our users ahead of time, and we create their username and password and give it to them. In this sense, we can be assured that the username and password are "strong".
However, our clients have requested additional security beyond this. Anyone have any ideas on how to add another layer of complexity to the security?
Our company used PhoneFactor and we absolutely love it.
We've also used Safeword Tokens in the past.
However, it's notthe only game in the book. I'd start by googling "Two factor authentication"
The OWASP guide to authentication is another good place to start. Actually, OWASP is the first place I'd look for ANY web security question.
Another option for additional security is to use a piece of physical 'evidence' such as a Smart Card: Protect Your Data Via Managed Code And The Windows Vista Smart Card APIs
There are lots of different areas that web apps can have their security improved on. Before getting started you need to determine what, exactly, your problem areas might be and what you want to focus on.
You might start this process by having a third party do Penetration Testing (PEN Testing) on your application. This should give a quick hit list of things you can take care of and, when you have a passing grade, is something to use in your sales literature.
Next you'll want to talk to your customers to understand what they mean by "more secure". Is it simply two factor authentication like David and Mitch mentioned or are they more concerned about things such as data in motion (ARP Poisoning, SSL, and the like), data at rest (everything from hard drive encryption to database encryption), authorization, impersonation (cross site and replay), personnel (ongoing background checks on who has access to the machines), etc..
The concept of security covers a lot of ground.