IE leaks keyboard events across frames, which causes a security concern.
The only recommendation I have found against this is to check if the content in the iframe is the topmost window, otherwise make it the topmost window.
if(top!=self)top.location=self.location;
Does anyone know of a better workaround?
Here is a link to the Public Advisory against the issue, it is quite old...
http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=77
A more reliable approach to preventing your site from being framed is to use the X-Frame-Options header. The link discusses clickjacking, but the countermeasure also applies to your question because the attack would require a malicious web site to frame your own site in order to start sniffing key events. (The link also points back to a coding horror article that describes the difficulties of JavaScript-based frame busting approaches.)
Here's some more background on frame busting. It includes a JavaScript-based technique, but prefers the X-Frame-Options method.
Related
What is a situation where nothing more than clearing your browser history will solve an issue with a web application?
"Clearing your history" does not include cookies or any sort of cache. Just the history. Is there any legitimate situation where asking someone to clear their browser history will solve a problem?
Short answer: There should never be such a situation, so, "none".
Longer answer: Well there are some possible interactions with history (window.history.go comes to mind) and it's possible that some websites could use some very convoluted systems to examine and ingest that history/.
(https://developer.mozilla.org/en-US/docs/Web/API/History_API for some brief overviews on how mozilla based browsers would do it)
But those are all nonsensical, unreliable, and remarkably bad design decisions for a web application to make. If you can clear your browser history and solve a problem with a web application, that web application is categorically awful and you should not use it.
EDIT: This presumes you're talking about location history. If you're asking how clearing the other historical data in your browser (such as cookies or cached data or local storage or perhaps download history) might affect the experience. there are plenty of ways that could affect the function of a site!
Is there a benefit to implementing micro-formats (or itemscope) in the html for a web app? So far it only looks like it is useful for seo and my web app is behind a login screen, so I will not have to worry about that. Are there any plugins or browsers which automatically process the information.
Or as unor proposed, is there a benefit in adding structured data to non-public sites?
If you generalize the question like unor proposed:
Is there a benefit in adding structured data to non-public sites?
It has got a definit advantage! For someone with visual disability it is easier to navigate through sites if micro-formats are implemented. If there is a possibility that someone with a screen reader will use the application it worth the effort. Not to mention that it is a one-time task with a long term positive effect. I think it is a good thing to proactively thrive to serve all kind of user.
Answer to the original question: browsers do not have to process those information, but some advanced technology could use it in the browser like preload. There was a research at my University about which pages to reload and those were using this feature. (Eg: in free time of the processor the browser plugin preloaded home to enhance the browsing experience.)
This is a web security "concept" question:
If you own 2 websites (A and B). AND you iframe in some content from B onto A. AND both websites have NOT been physically compromised (by "compromised" I mean that some hacker hasn't changed the source code on any page on the web server itself, and for the purposes of this theoretical discussion you can guarantee that). THEN, is there any (known) methods in exploiting frames in other ways?
The reason I ask this is that Youtube, Google Maps etc. are now providing iframe code as their default "embedding" method and we are internally having a debate about the wisdom of that!
If the only way that iframes can be exploited is by physically modifying the source code, we are proposing to build an system to actively monitor any changes to those few files we host that will contain an iframe tag. Do you think that is a satisfactory mitigation strategy?
Cheers, and thanks.
Trying to find a solution to this, we have our LMS Server, and content servers all across the US, so the user gets their content from the closest location.
I've come across a solution using SCO-Fetcher, mentioned in these two links below and illustrated below, but I cannot find any information on how to implement a similar solution.
here: http://elearningrandomwalk.blogspot.com/2006/08/sco-fetcher.html
and here: http://www.adlnet.gov/Technologies/scorm/SCORMSDocuments/SCORM%20Resources/ADL_CrossDomainScripting_1_0.pdf
If anyone has any thoughts or information regarding this, it would be most appreciated.
I work for a content provider who has had to interface with a lot of different LMSs and cross-domain has always been a painful issue.
The document you linked to not-withstanding, SCORM doesn't really cater for cross-domain at all. My experiences with cross-domain has been against the AICC standard. In the past we've used a signed java applet to perform the cross-domain communications, but currently we are using a little hidden flash* SWF file which we talk to via javascript. This requires the LMS to have a crossdomain.xml file installed on their web server to allow the communication, which some of our customers balk at.
* Our product heavily uses flash already, so this was not an onerous requirement for us.
The solution that we are seriously considering now is a variation on the "Run-time service on Content Server" as suggested in section 4.8 of the cross-domain scripting document.
The content server would run the courseware itself, as if it were an LMS, and proxy all the API calls to the real LMS. The diagram below shows the communication paths:
Also, your launch URL wouldn't be directly to the content (e.g., http://abc.com/content/sco.html) but to the software application on the content server (e.g., http://abc.com/access.php?content=sco.html&permissions=OAUTH_ID), which would then serve the content as if it was an LMS itself.
Also, just came across this article on cross-domain communication which, while not SCORM specific, might provide some alternative ideas for implementation.
I know this is an old question, but thought I'd share: I had a similar situation a few years ago and settled on an iframe hack to get around the cross-domain restrictions. All it requires is a bit of JavaScript and HTML. It works on older browsers, including IE6.
Chuck, what solution did you wind up using?
Web applications on uncompromised computers are vulnerable to XSS,CRSF,sql injection attacks and cookie stealing in unsecure wifi environments.
To prevent those security issues there are the folowing remedies
sql injection: a good datamapper(like linq-to-sql) does not have the risk of sql injection (am i naïeve to believe this?)
CSRF: Every form-post is verified with the <%:Html.AntiForgeryToken() %> (this is a token in a asp.net mvc environment that is stored in a cookie and verified on the server)
XSS: every form that is allowed to post html is converted, only bb code is allowed, the rest is encoded . All possible save actions are done with a post event so rogue img tags should have no effect
cookie stealing: https
Am i now invulnerable to web-based hacking attempts(when implemented correctly)? Or am i missing some other security issues in web-development?(except for possible holes in the OS platform or other software)
The easy answer is "No you're not invulnerable - nobody is!"
This is a good start, but there are a few other things you could do. The main one you haven't mentioned is validation of untrusted data against a white-list and this is important as it spans multiple exploits such as both SQLi and XSS. Take a look at OWASP Top 10 for .NET developers part 1: Injection and in particular, the section about "All input must be validated against a whitelist of acceptable value ranges".
Next up, you should apply the principle of least privilege to the accounts connecting to your SQL Server. See the heading under this name in the previous link.
Given you're working with ASP.NET, make sure Request Validation remains on and if you absolutely, positively need to disable it, just do it at a page level. More on this in Request Validation, DotNetNuke and design utopia.
For your output encoding, the main thing is to ensure that you're encoding for the right context. HTML encoding != JavaScript encoding != CSS encoding. More on this in OWASP Top 10 for .NET developers part 2: Cross-Site Scripting (XSS).
For the cookies, make them HTTP only and if possible, only allow them to be served securely (if you're happy to only run over HTTPS). Try putting your web.config through the web.config security analyser which will help point you in the right direction.
Another CSRF defense - albeit one with a usability impact - is CAPTCHA. Obviously you want to use this sparingly but if you've got any really critical functions you want to protect, this puts a pretty swift stop to it. More in OWASP Top 10 for .NET developers part 5: Cross-Site Request Forgery (CSRF).
Other than that, it sounds like you're aware of many of the important principles. It won't make you invulnerable, but it's a good start.
Am I now invulnerable to web-based hacking attempts?
Because, no matter how good you are, everyone makes mistakes, the answer is no. You almost certainly forgot to sanitize some input, or use some anti-forgery token. If you haven't now, you or another developer will as your application grows larger.
This is one of the reason we use frameworks - MVC, for example, will automatically generate anti-CSRF tokens, while LINQ-to-SQL (as you mentioned) will sanitize input for the database. So, if you are not already using a framework which makes anti-XSS and anti-CSRF measures the default, you should begin now.
Of course, these will protect you against these specific threats, but it's never possible to be secure against all threats. For instance, if you have an insecure SQL-connection password, it's possible that someone will brute-force your DB password and gain access. If you don't keep your versions of .Net/SQL-Server/everything up to date, you could be the victim of online worm (and even if you do, it's still possible to be zero-dayed).
There are even problems you can't solve in software: A script kiddie could DDOS your site. Your server-company could go bankrupt. A shady competitor could simply take a hedge-clippers to your internet line. Your warehouse could burn down. A developer could sell the source-code to a company in Russia.
The point is, again, you can't ever be secure against everything - you can only be secure against specific threats.
This is the definitive guide to web attacks. Also, I would recommend you use Metasploit against your web app.
It definitely is not enough! There are several other security issues you have to keep in mind when developing a web-app.
To get an overview you can use the OWASP Top-Ten
I think this is an very interesting post to read when thinking about web-security: What should a developer know before building a public web site?
There is a section about security that contains good links for most of the threats you are facing when developing web-apps.
The most important thing to keep in mind when thinking about security is:
Never trust user input!
[I am answering to this "old" question because I think it is always an actual topic.]
About what you didn't mention:
You missed a dangerous attack in MVC frameworks: Over Posting Attack
You also missed the most annoying threats: Denial of Service
You also should pay enough attention to file uploads (if any...) and many more...
About what you mentioned:
XSS is really really really waster and more annoying to mitigate. There are several types of encoding including Html Encoding, Javascript Encoding, CSS Encoding, Html Attribute Encoding, Url Encoding, ...
Each of them should be performed to the proper content, in the proper place - i.e. Just doing Html Encoding the content is not enough in all situations.
And the most annoying about XSS, is that there are some situations that you should perform Combinational Encoding(i.e. first JavascriptEncode and then HtmlEncode...!!!)
Take a look at the following link to become more familiar with a nightmare called XSS...!!!
XSS Filter Evasion Cheat Sheet - OWASP