I have a requirement to paste text from a textarea into the DOM as a preview area, much like the one you get on Stackoverflow when you make a comment etc.
I allow users to insert any and all html tags, including javascript tags. I know this will allow embedded javascript and flash content etc, but I then remove all of this server side so no other user will see, they just see plain text.
However are there any security issues in letting the user insert these things in there own page?
My guess is there isn't otherwise tools like firebug would be a security risk, but I'm not sure.
However are there any security issues in letting the user insert these things in there own page?
I can't see any - the DOM is freely manipulable in the client's browser, anyway. Whether they do it using a tool like Firebug or your JavaScript function, doesn't matter.
As long as the data isn't shown unfiltered in other users' browsers, I think you're safe doing this.
Actually in rare set of circumstance, it might be an issue. It highly depends on how this particular feature works, but I can imagine making first use of CSRF to 'post' in the preview area some malicious javascript/ajax, and use that to steal cookies, change account password or whatever tickles your fancy.
So the attack would go something like this; I send a user a link to a 'legitimate' website. On that website there is a hidden payload (eg via img tag in case of GET, or hidden iframe with auto-submitting form for POST) which silently redirects the user to your website with the XSS payload, which then will be executed by the user through the injection in the preview area, for instance logging user's cookies, without him ever knowing.
Again it all depends how your preview feature works, and if you for instance use form tokens etc., but the point is that it in fact could be an issue.
Related
I want to disable Ctrl+U from browser to stop users viewing the source (html + JavaScript) for a page.
This unfortunately is not how it works.
When a user visits your website, there's a lot going on behind the scenes:
The user queries a page on your site.
Your server does some fancy things
Your server transforms those fancy things into something for the users browser to use
Your server sends off its final product back to the browser.
The browser then gets a bunch of code, such as HTML or Javascript.
The browser then reads that HTML and Javascript and organizes it to look and work how it's supposed to on the users screen.
Basically, another way of saying all this, is that the HTML and Javascript that you want to hide is executed client-side. This means that your browser gets a bunch of code, it executes it, and then displays its results to the user. If someone really wanted to see the source code of your website, they could easily bypass your prevention of using CTRL+U. All they have to do is to somehow tell the browser not to execute the code!
Ultimately, if a user really wants to see your source code, they will do it. There is no way to stop it. For this reason, it is recommended to keep things you need to remain a secret on the server-side code (such as your PHP).
You potentially can not prevent user from viewing the html source content. The site that prevents user from rightclick. but Fact is you can still do Ctrl+U in firefox and chrome to view source !
It is impossible to effectively hide the HTML, JavaScript, or any other resource sent to the client. Impossible, and isn't all that useful either.
Furthermore, don't try to disable right-click, as there are many other items on that menu (such as print!) that people use regularly.
Please have a look at this
I think this may help you.
Unfortunately CTRL+U is for "View Source", you can't disable browser functionalities, but you can write secure coding whichever you don't want to show.
I want to automatically log in to specific websites, e.g. the groupware webinterface at work. My browser (Chrome on Linux, if that matters) saves passwords for me, but I want a complete auto-login, so that I don't even have to click the "login" button anymore.
I have investigated multiple ways to approach this, but none of them has turned out to be satisfying:
1. Use a Tampermonkey JavaScript which clicks the "login" button on the website
I wrote a custom JavaScript which was supposed to just click the "submit" button once I load the login page. Chrome was supposed to fill in the password fields. The idea sounded pretty straight-forward. However, this is bad for 2 reasons: On the one hand, I cannot use Chrome's saved password. Chrome has a policy that the password field already displays the circles, but the password is not actually filled in and is also not accessible from JavaScript until the user has performed a gesture such as clicking (see this Chromium issue), which kind of defeats the purpose of my JavaScript. I could go around this by saving the password in localStorage additionally (security wouldn't be compromised, as the saved passwords are not encrypted either), but this doesn't feel good. On the other hand, this breaks a (imho) significant security feature of Chrome. It is the same feature mentioned above which prevents XSS attacks from stealing login passwords. Because whenever I load the login page, the password would be filled in and it would log me in.
So what I would rather want is a special (if possible local) page which I can bookmark, but which will (probably) never be known to anyone performing an XSS attack on me.
2. Use a local HTML page which loads the login page, fills out the form and logs me in
This is a simple idea and would accomplish my goal, but of course it doesn't work because of the same-origin policy.
3. Use a script/program
This would theoretically work. I could write a program which downloads the login page, reads the form, submits it and then transfers the cookies (or the login URL, if the form uses GET to submit to the browser. However, this would be a major piece of work, especially for the case where the forms use the POST method (I'd have to transfer cookies to a possibly running instance of Chrome).
Plus, I'd have to somehow tie this program to a local webserver or turn it into an extension so I could access it from within my browser. After all, opening a shell and typing a command is not really easier than clicking a login button.
4. Use cookies
This is not really an approach, but I mention it here for completeness' sake. By default, Chrome removes all cookies when I exit the browser. I can configure it to keep the cookies of specific websites so I don't have to log in again when I restart it. Some websites use only session cookies, though, so closing the last tab already (correctly) removes the cookies and I have to login again. As a result, cookies only solve my problem for a few websites, but not all.
So my question is: Is there an easier way to accomplish automatic log-in without having to circumvent security features or write a large program?
P.S.: I know, this is a lot of effort to get around clicking a single button every now and then :)
I have created a webpage but my friends or collegues always copy the source code and copy all the data easily, so is there any way to hide page source option from browser ?
As a rule, if you are putting information on another user's computer (whether because you made a document or they viewed your webpage), you really can't control what they do with it.
This is an issue that larger companies deal with often. Have you heard of DRM? It's a mechanism that companies like to try to use to control how people can connect to their services, use their content and in general, try to exert control over their data while it's on your system.
Now, a web page is a relatively simple container for holding information. You expressed an urge to prevent your friends from copying the source code. You could try to encrypt it, but if it's using local data to decrypt itself, there still isn't going to be anything that stops them from just copying what's in the View Source window and running it again (even if they can't really read it).
I'd suggest that you don't worry about it. If what you have on your page is so important that others shouldn't be able to see it, don't put it on a webpage.
Finally, Google doesn't much care that you're able to view the source to their home page. Why not? Because the value of the search engine isn't in what the home page looks like, but in the data on the back-end that you don't have direct access to. The value is in the algorithms that execute on the server when you hit that Google Search button that queries that data and returns the information you're looking for. There's very little relative value in the generated HTML that you see in the page. Take a leaf from their book and don't stress that they copy your HTML.
No , there isnt any way to do it, however you can disable right clicking in browser via javascript, but still they can use shortkeys to open developer view (in chrome F12) and see the source. You cannot hide html or javascript from client, but maybe you can make it harder to read.
No. Your HTML output is in the user's realm. Even if there was a way to disable view source in one client, a user could use a different one
Always assume that your site's HTML is fully available to end users.
Yes and no. You can definitely make HTML and JS harder to intrepret by obfuscating your code - that is, taking your code and making it look confusing. Here is a tool that can do that: http://www.colddata.com/developers/online_tools/obfuscator.shtml
However, these things all use code, and code can be decrypted through any number of methods. If you post a song to the internet, even if they cannot find the mp3, they can simply record their speakers. If you upload an image and prevent users from downloading it, they can take a screenshot or use their camera. In order for HTML and Javascript to work, it has to be intrepreted by their computer, and even if you do find a way to disable "View Source" there are others ways, like a DOM inspector (F12 in IE/Chrome, Ctrl+Shift+K in Firefox).
As a workaround, use copyright, warn your users they will be punished if they copy your code, and put watermarks, labels and logos over any mp3s or images you don't want stolen. In the end, disabling right clicking (which is also possible, see How do I disable right click on my web page? ) or disabling selection (also possible) does nothing, because there is more than one way to get your code, like searching through temporary internet files.
However, you ask "what if I want a site where my users can log in and I need security? How can I make it so nobody can see my code then? Doesn't it have to be secure and not out in the open?"
And the answer is, yes, it needs to be secure. That's what server-side languages, like PHP, are for. PHP does all the work on the server itself so the user cannot see it. PHP is like a pre-rendered language - rather than doing it in real-time, PHP does all the work beforehand so the user's computer doesn't have to, making the code safe. The code is never put onto the user's computer, because the user's computer doesn't need it. The work is done by the website itself before the page is sent. SSL is often paired with PHP to make absolutely sure that websites have not been hacked.
But HTML and Javascript have to be done in real time on the user's computer, so you cannot disable View Source because it is useless. There are many, many ways that users could get around it, even if View Source is disabled, and even if right clicking is disabled.
If your code doesn't need to be secure, however, I'd recommend you consider keeping it open source. :)
I'm currently working on a content generator and I have objects which allow users to add custom scripts to the page.
I'm concerned about the preview of my plugin. Pages cannot be saved in the preview, but can the user mess with my preview page permanently if I allow him to use dynamically added javascript?
I'd also like to mention, the javascript is sent via AJAX to a php file, then appended to the body.
Pages cannot be saved in the preview, but can the user mess with my preview page permanently if I allow him to use dynamically added javascript?
Not permanently, no. He can only mess up his own current page.
If the custom scripts and pages don't leave the client's computer, or you can make sure they will not be served to other people (which implies they're not stored on the server) then you're safe from XSS attacks.
However, notice that as soon as your plugin leaves "preview" and you allow saving pages that are shown to other visitors, you will have that problem.
Yes, this is a big attack vector known as Cross Site Scripting (XSS). You should never run JavaScript provided by your users on arbitrary pages, unless you absolutely must.
For instance, I could add:
document.body.style.display = 'none';
and that would hide the entire page.
Although your script only displays to the current user, your page may be vulnerable to a Cross Site Scripting attack. The way to handle it in this case (as you are allowing scripts) is to use a similar mechanism to a Cross Site Request Forgery prevention (although CSRF and XSS are completely different).
e.g. if your page https://www.example.com/preview displays all content (HTML and script) POSTed to it (for thie example assume the POSt parameter is called content), an attacker may include the following code on their page and then entice the victim to visit it whilst logged into your website.
On www.evil.com:-
<form method="post" action="https://www.example.com/preview">
<input type="hidden" name="content" value="<script>alert('foo');</script>" />
</form>
and this form could be submitted automatically via JavaScript (document.forms[0].submit()).
This will cause the script in content to be executed in the context of your site, possibly passing cookie values of the user's session to www.evil.com rather than my benign example of an alert box.
However, as your are POSTing the content value to your own site using AJAX, you can prevent this attack by checking that the X-Requested-With request header is set to XMLHttpRequest. This header cannot be POSTed cross domain (without your server agreeing to this using CORS).
Also, if your page is for a preview - what is the preview for if your preview cannot be saved? If this is related to your full save functionality, then it is possible to allow a user to save scripts safely by running the entered content within a sandbox.
I want know if you can guide to users for a series of steps that imply visit different web pages using actions inside a Bookmarklet. What I want is a kind of Wizard or automated actions cross web pages.
Afraid not. What you're describing would actually be very dangerous. If there were any malicious code in the bookmarklet, it would have access to every site you are logged into, email, amazon etc. Some pseudocode for an attack could look like this:
window.location = "www.gmail.com";
ajax.post("www.gmail.com/deleteAllMail");
window.location = "www.amazon.com";
ajax.post("www.amazon.com/buyReallyExpensiveStuff");
You partially can, if you open the new pages inside an iframe. However, you won't be able to modifying the content of the webpages anymore, but just modifying the url of the iframe, and going through different websites (like a kind of slideshow).
Notice that if you're the owner of the pages, you can use postMessage to interact with them, even if they're in different domains.
Or, you could do a "tunneling" on server side, and inject each team you got the page back with the JS you need.
But probably the cleanest approach if you're not the owner of the pages is just create a simple restartless add-on for the browsers you want to support.