I'm using CakePHP 2.6. I want to create a website like blogger(blogspot) where every registered user has its subdomain and can add its articles add javascript codes.
Is is safe to allow registered users to add javascripts on their subdomains?
Thanks
Is is safe to allow registered users to add javascripts on their
subdomains?
If done right yes. Search for JSONP, CSRF, XSS, CORS, and same origin policy.
I'm clearly not going to explain all of this in an answer, it is far to much for this place here.
Allowing arbitrary JavaScript, Flash and other active content (such as iframes etc...) from untrusted sources carries a security risk. JavaScript and other active content can be used for malicious purposes through the use of Cross-Site Scripting (XSS).
Allowing JavaScript from untrusted sources has caused issues in the past (one of the most famous examples of this was the MySpace XSS worm).
For an overview on XSS I suggest you take a look at the following resource from Acunetix.
Related
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.
In another question dealing with a bug in blackberry10 that denies cross origin XHR calls, it is proposed to get around the issue by disabling web security.
But what does disabling web security really imply here? Am I going to torture small harmless woodland creatures if I use this?
Seriously though, does doing this expose my app to additional security risks beyond those introduced when adding the popular wildcard access uri="*" or access origin="*" line in my config.xml for blackberry10?
please advice
But what does disabling web security really imply here? Am I going to torture small harmless woodland creatures if I use this?
No.
It means your application could access ANY resource in the Internet good, bad or ugly IF (and only if) the user is able to navigate / access that resource.
By disabling web security, the following scenario could happen:
If you published a link in your app to a remote page that you do not control, you risk that page may display unexpected/malicious/inappropriate content OR enable the user to navigate elsewhere to another page that might. Example: Say you are display content in your app loaded directly from some remote URL. Do you know exactly what type of content your users might 'see' in your app? If that remote URL was loading 'buy these pills now to get huge' advertisements from a different URL, would you be okay with YOUR users seeing that content in YOUR app?
Most devs will only include content in their app that they 'trust' and white list just the specific urls they need. However, sometimes you do need to unlock the front door if you don't know what URL your users want to access.
So disabling web security is available if you really need it, but not recommended. Use it at your own risk, not as a matter of convenience.
I am currently working on security for a website (JSP) that contains 2 pages: a login and a data page. Once a user logs in, he is able to SELECT data from a specific table with read only access.
After browsing security risks online, I have wrote down a general list of what I might have to defend against
Injections
XSS
Auth / Session hijacking
CSRF
Direct Object Ref
Currently, I am reading about how to defend these attacks and what I should include in my code. However, I won't really know if my code actually works unless I test these attacks out for myself (and even then, there still might be other attacks that work). Right now, I just want some security, and thus I need to know how to produce these attacks so I can try them on my site.
Injections were simple as all I had to do what type '1'='1 in my code to reveal that it was flawed. Then I used prepared statements and SQL injections didn't work anymore.
How can I produce the rest of these attacks to see if my security atleast works against basic attacks?
(Also, is there perhaps some safe site or tool I can use to test out my vulnerabilities?)
I assume from your list that you're looking at the Open Web Application Security Project Top Ten. Good!
Really, the best advice I can give is to read through the OWASP site. A good first step would be to go through the individual links on that page (e.g. Broken Authentication and Session Management) and check the "Am I vulnerable?" section. Here are some further hints:
XSS
The XSS Cheat Sheet can be pretty helpful here. More examples than you can shake a stick at, ready to paste into your site.
CSRF
OWASP's wiki has a CSRF Testing Guide full of great links and suggestions.
Auth/Session hijacking
Well, are you using HTTPS? See this answer for more.
More resources
If you want to Go Deeper and do some real testing, here are some things you can do:
Read the Web Application Hacker's Handbook.
Try out some of the examples on http://hackthissite.org and the Google Gruyere project and see if you can break into them.
Download Kali Linux and learn to use some of the tools that come with it.
Go to a security conference or minicon near you and connect with other infosec people. Maybe I'll see you there :)
What are the security aspects of second-level domains like .co.uk?
Especially, when it comes to cross-site scripting and cookies stealing.
Many of basic security mechanisms on client rely on different 2nd-level comain names.
Does a developer keep special attention when developing for e.g. foo.co.uk?
Browsers are using a list of effective TLDs, instead of relying only on the level of the domain, for things such as allowing sites to set a cookie.
See http://publicsuffix.org/list/ . As seen here, this is used by Firefox, Chrome and Opera.
I'm planning a webapp that will allow users to create resources without signing in. I plan on using the Google Docs / Pastebin style of security by creating unique hard-to-guess URLs. (e.g. example.com/ytasdfweoirue/)
What are some things to watch out for? What guidelines would you use in designing the token generator? What are some things I should consider? Is there a best set of characters to choose from?
My backend will likely be CouchDB, but I'm interested in platform agnostic, general guidelines and problems that might crop up in any platform.
Use PRNG
You should generate a random URL with a PRNG, not with your framework's simplest Random() function. (FYI In theory .NET GUID is not designed for security, in practice in a web app you should be fine, but you've been warned)
Do not include 3rd party resources in the "hidden" page
Ensure that the page visitors visit do not include any 3rd party resources (javascripts, images, flash animations etc.) Pretty much all of them will leak the the current URL via REFERRER and your hidden URL will be exposed to all those 3rd parties. This is same even if you are using HTTPS and included URLs are using HTTPs.
Do not include links to 3rd party websites, if you have to then take care of Referrers
Again REFERRER leaking can be a problem if the page you are serving includes links to 3rd party URLs. In which case you can either redirect them from a common page (if you do so be careful about Open Redirect vulnerabilities) or you can use a JavaScript trick to strip REFERRER.
You don't mention your technology stack, but the best option here sounds like a Guid. Just have your url:
http://whatever.com/resource/{guid}
Guids are long enough to be hard / impossible to guess or enumerate and you have a pretty strong guarantee that you won't generate two guids that are the same. As long as you aren't in javascript, your language should have a guid generator available as a built in (.net) or a library.
Here is the wikipedia page for more discussion: http://en.wikipedia.org/wiki/Globally_unique_identifier