I have been advised to implement the following items in our ASP.NET MVC Core site to prevent a BREACH attack. How do you implement them?
Separate the secrets from the user input.
Randomize the secrets in each client request.
Mask secrets (effectively randomizing by XORing with a random secret per
request).
Obfuscate the length of web responses by adding random amounts of arbitrary
bytes.
We have already implemented Anti-Cross Site Forgery Tokens on every form and turned off Http Level Compression.
Any help would be greatly appreciated.
This is reported by this tool:
https://www.acunetix.com/
Thank you in advance.
All I did was disabling HTTP compression in IIS and the BREACH ATTACH issue was no longer raise by our security scans.
As mentioned by #Isa "Disabling HTTP compression in IIS"
you can find the tips in this article
there is a section, titled
"HOW TO ENABLE OR DISABLE STATIC AND DYNAMIC COMPRESSION FOR A SITE OR APPLICATION"
I have disabled the dynamic compression, retested and passed.
Related
Something seems to elude me with regard to xAPI. I am going to try and keep this really simple.(and maybe even stupid)
What I understand to be true...
Any Tin Can implemented content can be launched with a launcher.
The launcher is provides endpoint and auth information
The endpoint DOES NOT have to be an LRS. It can be a script which then passed to the final endpoint, which is an LRS.
The LRS, in this case private SCORM Cloud(sandbox), cannot receive statements without basic auth.
What I need to know...
Does the LRS generate OAuth tokens?
How would someone pass the statement from Captivate, Storyline, lectora files to a the TinCan_PHP for handling secure connectioni to the LRS?
Why would I use TinCan.JS, when the basic auth information is easily broadcasted to the end user, which could then be used to cause harm to the LRS?
Am I completely off track?
Thanks a lot...
Just some clarifications for future users on your understanding...
A launcher may provide endpoint and auth, that is one scenario and is probably based on the launch guidelines that came out with the 0.9 spec. There are other ways to handle the handshake, for instance how cmi5 does so (which isn't necessarily any more secure other than the fact that the credentials can only be requested once and are intentionally denied certain privileges such as voiding of statements).
I would consider your "script" a 'non-conformant' LRS in that it is receiving statements (in the form of xAPI requests), but doesn't provide full LRS conformance. SCORM Cloud's LRS can't receive statements without some authentication, but you are correct basic is preferred because OAuth there doesn't make much sense for production.
For the questions...
Yes, the LRS generates OAuth tokens, but for the most common approach the content has to have an already established relationship with that LRS and the OAuth based account has to be on the LRS (or a system the LRS is tightly coupled with, like an LMS) not with some OAuth provider in the wild (meaning you can't use accounts on Twitter, or Facebook, or Google, etc. which is the part that is often confusing for people).
They wouldn't, those products all already support direct communication to an LRS via the launch guidelines (Basic Auth), any system they are communicating with has to have at least enough LRS functionality to support them which includes the State API besides the Statements API.
TinCanJS in and of itself isn't a browser only solution, there are people running it on the server side so the language is really a separate issue. It is also possible to use TinCanJS outside the common launch paradigm, and in such situations it is possible that the user has an individual credential with the LRS in question (or a system that is coupled with the LRS) and they enter it themselves. A bookmarklet is a good example application.
The bottom line with all sets of credentials is to make sure your application is conversing with the LRS over https in which case the credential used isn't in the open, then check with the LRS provider to see if it is possible to use credentials that are short lived and have limited permissions. There is little "harm" that can be done to a properly implemented LRS short of voiding of statements or overwriting (deleting) of stored documents, both of which can be limited when using a proper permissions scheme and limited credential.
To answer your question, yes you are completely off track! :-)
If you're sending statements from a javascript based e-learning course to somewhere, then than connection is inherently not secure. Adding another (secure or otherwise) link in the chain after that insecure connection doesn't add to your security. You may as well send the xAPI statements directly to the LRS.
You may as well use Basic HTTP authentication too. Firstly, that's what all the authoring tools support, so you kind of have to. Secondly, using OAuth instead of Basic Auth for client side connections is like using a key lock instead of a combination lock and then leaving the key under mat. A key lock (OAuth) might be more theoretically secure than a combination lock (Basic Auth) but not in practice if you leave the key under the doormat (embedded in your client side code).
See this SO question answer for three options of what you can do about xAPI authentication security.
And just for the sake of completeness: yes, in the case of OAuth the LRS generates the tokens. See the xAPI spec for the most up to date details.
As part of an application my users can create documents with embedded images/files/text etc. Viewing and editing this content requires the user to log in. At the moment the images and files though are delivered as permanent links so if those links are shared any non-authenticated user can access them forever.
I would like to make these files secure. My initial thought was to use the login token and user's id to check if they have access and only deliver the files if they do. But then I started working on it and it seems the most practical solution would involve generating a link that will expire at some point in the future. This doesn't remove the exposure to unauthenticated access but maybe reduces it enough.
The questions that come to mind are:
Is there a common approach or a few options on how this should be implemented?
I've seen returning urls with expiration periods used
Google docs seems to do something more sophisticated for it's embedded images but I can't tell what
Others?
Basic design points?
Pros/Cons of each?
Yes, it reduces the authenticated access to a fixed time but theoretically it provides un-authenticated access. So a security professional will claim it has no authentication. This kind of timed expiry link is usually used to safeguard against one time un-authenticated access like password reset(along with an expiring token independent from the time).
What is your goal? From whom are you trying to protect the data? Is the users who already have access to files and you want to limit providing an expiry time? From the question, you need to secure the access to the files/documents which has text and embedded images in it from everyone. You are right about the timed expiry design. It will not guarantee you authentication and integrity of the document and if it is over non-secure HTTP it will not even provide you integrity of the document from a potential adversary.
you can use cookies(secure cookie) over HTTPS. As long as the user has the non-expired cookie, allow access to the files/documents. The cookie approach needs distributed cookie management if you to host the solution in multiple boxes with a reverse proxy in-front. Though cross-site scripting is a threat but still most of major web application providers are using cookie based solutions. Please note, cookie breaks the REST nature of the web-application.
Another approach (similar to cookie) is to generate authenticated tokens tied to user/documents which has access for N number of attempts for a time period set while generating the token. This method has to be used over HTTPS to avoid un-wanted listeners.
An always changing link is very costly to manage and not scalable over time because it is too much state to manage and application crash makes it even more costly. Re-directing to authentication is a safe bet for you provided you have already cookie management in place or you have one application instance to take care of.
Or you can you HTTP digest authentication provided that your framework supports it so that you do not have to worry about the cookie-hell. Please note that you may need to write up some client-side java script based on your use case.
We have a .Net Web API (v2) serving an SPA that I aim to secure using OAuth 2.
In my OWIN Startup.Configuration(), I set my Provider in IAppBuilder.UseOAuthAuthorizationServer to an override of OAuthAuthorizationServerProvider. I have this successfully providing refresh tokens.
I want to be sure that these tokens cannot be spoofed by someone implementing a similar provider. No searching I have done has given me any kind of answer.
Does OAuthAuthorizationServerProvider ensure that the refresh tokens received are those issued by itself, and not any similar code on a hacker's machine?
My own experiment seems to confirm that it does - I tried the same code running on two different machines and took the unexpired refresh token (with a long expiry of 24 hours) from the other machine, and got a 401 as I'd hope. But just in case I've wrongly convinced myself, I'd like some reassurance and/ or advice from someone who knows more about OAuth in the .Net Web API than I.
Thanks,
Paul
I'm sure I eventually found a definitive answer in the doc for OAuthAuthorizationServerProvider but now can't find it.
However, Dominick Baier, an expert in this field, says:
Access tokens are protected using the machine key. Protection of refresh tokens is up to you. You need to manually set the machineKey element in web.config (otherwise the key gets auto generated and might change over time).
His comment comes from a reply to a post on implementing OAuthAuthorizationServerProvider.
I am trying to integrate two separate web applications - one is an existing custom web application with it's own security paradigm and the other is a reporting platform (JasperServer). I want to be able to use Jasper's web services interface to integrate the reporting functionality into our application. Our security model is complex and is home grown but I think there is hope.
We set a cookie that is an encrypted string containing a web service URI as the authentication source and a token which is stored in the database that is created when the user logs in and is destroyed when he/she logs out. I think I can leverage this to implement a kind of SSO in Jasper since it uses Spring Security.
What I THINK I should do is implement a pre-authentication filter that checks for the cookie I mentioned above. It could then decrypt it, make a web service call to the authentication source provided to verify the token is active in the database. If it is, that token can be used to point to user and role information that could be returned as a UserDetails object.
Unfortunately, I know enough to be dangerous but not enough to be effective. Am I on the right track? Does this solution sound tenable? If so, where would be a good place to start and are there any examples of something similar you could point me to? I've searched around quite a bit and have found nothing that quite fits the bill.
Thanks in advance to any and all who can provide me a glimmer of hope
Cookies are tied to a domain/subdomain/path and port. It is possible to set a cookie at the domain level so if you have something like webapp.mydomain.com and jasper.mydomain.com you may be ok assuming they are on the same port.
However be very careful about implementing your own SSO/Authentication framework. It requires a great deal of thought. As it stands your proposed implementation would be vulnerable to: replay, man in the middle, and XSRF attacks ... there may be other vulnerabilities but these are just 3 that come to mind ... sorry! :D
Why was this policy even created? Seems to me that there are only disadvantages of this. If you want to, there are ways to access another domain (for example, JSONP). Wouldn't it be much easier for everybody if there was no such policy?
But I suppose that the guys who created it are smart and that they did it for a reason. I'd like to know this reason.
Same Origin Policy is not primarily meant to defend against Cross Site Scripting (XSS) as stated above but to hinder Cross Site Request Forgery (CSRF).
A malicious site shall not be able to load data from other sites unless this is allowed by that other host explicitly.
E.g. When I browse www.malicious.com I would not want it to be able to access my concurrent authenticated session at www.mybank.com, request some of my data from the bank's AJAX interface and send it to malicious.com using my browser as relay.
To bypass this restriction for intended use or public information the Cross-Origin Resource Sharing (CORS) protocol has been implemented in modern browsers.
Security.
If it didn't exist, and your site accepted input from a user, I could do bad things. For example, I could put some javascript in the text I entered on your site, that did an ajax call to my domain. When anyone viewed my input (like on SO, when we view your question), that javascript would execute. I could look at how your website worked in my inspector, add observers to your input, and steal your users' data.
The same origin policy prevents me from sending your data to my domain via ajax. To see how easy it is, if you have a simple website, just put the following in one of your forms and submit the data.
javascript:alert(document.cookie);
If you don't take steps to do something about that (your framework might automatically), I just injected javascript into your site, and when someone views it it will execute. (It's called javascript injection)
Now imagine I got a little more creative and added some ajax code....
The browser needs to prevent such things or using the web would be digital suicide.