This might be a silly question but i want to clarify this. what happens when we close a javascript two times.
<script type="text/javascript">
alert("hello");
</script>
</script>
i did this but am not getting any error.its like we closed the script so there wont be any execution so no error will trigger i believe. will this create trouble under any situation?
why am asking this is i would like to insert a </script> at the end of a plugin where user submits their script. So that i don't have to go for extra coding on validation if this works fine without creating any trouble
The browser will treat this as an extra, unexpected end tag. It doesn't matter that it's </script>, it could also be </link> or anything else allowed in the same context.
Most browers will silently ignore such extra tags unless you enable strict / XML mode. For strict mode, you should get errors in the console.
To properly wrap plugins supplied by the user, I suggest this strategy:
Always wrap them in your own tags (so you can be sure the structure is always correct).
Check the string that you put between the two tags for <script, <script> and </script> and report an error if you find any of them.
The idea here is that users should never use script tags in their code and that you put them where they belong.
Most browsers will just remove/ignore an extra tag. I can't see that it's would cause any problems, but it is quite an ugly way to do it. I have no better suggestion currently though.
nothing. the browser ignores it but it will obviously not pass standards.
as far as i know, if the browser comes across an opening <script> tag, it assumes everything until the closing </script> tag is script. so starting with a </script> will have no effect but to cause an 'unexpected` exception.
The effect may change depending on the browser, but in teory all ignore the second tag.
XHTML rules are much stricter than those of HTML. When special XML
characters (such as & and <) are used in scripts in XHTML files, they
cause errors. The simplest workaround is to use external script files.
However, if you simply must write inline scripts, then you will need
to include CDATA (character data) sections in your file. Within CDATA
sections the special XML characters can be used freely. The following
example uses a CDATA section that is compatible with both XHTML and
HTML syntax.
<script type="text/javascript">
//<![CDATA[
alert((1 < 2) && (3 > 2));
//]]>
</script>
Also it is not a correct practice and if the script is inline than it will break W3C compliance.
To answer your direct question: Nothing would happen, it's just invalid (x)HTML which the browser ignores.
To answer your indirect question, turned out in the comments:
#DanFromGermany So you are saying validation is the only way there otherwise this way is not recomended
Validation of external resources is always critical.
For example, simply reading external scripts into <script></script> tags, tells the browser "this is no external content" and hereby grants more access, for example, read your cookies and set cookies originating from your domain (external content....your domain).
Including external JS via <script src="...">, from a different host/domain, tells the browser "this is a 3rd party script, don't allow it as much as internal scripts." It is therefore not allowed to read or set your cookies and stuff.
Why putting in </script> does not help:
An attacker is easily able to screw your whole website and let it easily disappear.
See the following:
<script>
<!-- external script start -->
</script>
</head>
<body>
Attackers website start
<div style="display:hidden;">
everything below disappears
<!--
<!-- external script end -->
</script>
</head>
<body>
<!-- your website start !-->
Still if you prevent this, an attacker can always use document.write(); to insert HTML into your Website.
Probably the best way is to executed the given JS through an iframe, from a blank page and an independent (sub)domain.
Putting things into database, or save ones JS and let it execute by a different user needs additional validation.
Related
I never thought to ask this, but I work on a security product and so we implement pretty strict protection against XSS:
We disallow < and > in user input both server- and client-side
If the user does manage to make a request containing either of those characters, the server will disable their account and leave a warning for an admin
Angular also sanitizes interpolated content before injecting it into the DOM
This is all great and dandy, except, it hurts UX and it's bad for performance. Surely, SURELY, there is a way to just tell the browser NOT to execute <script> tags added after initial document parsing, right? We use a modern bundled workflow and any lazy-loading of JavaScript will be done via import("/some/js/module") calls which get rebased by the bundler but will never be fed a dynamic value at runtime.
Even if there isn't a way to straight up tell the browser not to run dynamically added (by JS after page load) <script> tags, is there a tried and true workflow for rendering, say, markdown + HTML subset user-produced content in iframes? I am familiar with iframes at a high-level, but I mean can the parent document/page manipulate the DOM content of the iframe or something so even if it does add a <script> tag inside the iframe, the script code will not have access to the parent document's JS environment?
Actually that would be cool as a sandboxed way to display user content because they could intentionally include a script and make a little interactive widget for other users to mess with, in theory (maybe an antifeature in practice).
You can do it with CSP (Content Security Policy)
https://developers.google.com/web/fundamentals/security/csp#inline-code-considered-harmful
Example:
Allow only :
<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
// Some inline code I can't remove yet, but need to asap.
</script>
with
Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'
Start by blocking all with:
default-src 'none'
I'm not a full-time Javascript developer. We have a web app and one piece is to write out a small informational widget onto another domain. This literally is just a html table with some values written out into it. I have had to do this a couple of times over the past 8 years and I always end up doing it via a script that just document.write's out the table.
For example:
document.write('<table border="1"><tr><td>here is some content</td></tr></table>');
on theirdomain.com
<body>
....
<script src='http://ourdomain.com/arc/v1/api/inventory/1' type='text/javascript'></script>
.....
</body>
I always think this is a bit ugly but it works fine and we always have control over the content (or a trusted representative has control such as like your current inventory or something). So another project like this came up and I coded it up in like 5 minutes using document.write. Somebody else thinks this is just too ugly but I don't see what the problem is. Re the widget aspect, I have also done iframe and jsonp implementations but iframe tends not to play well with other site's css and jsonp tends to just be too much. Is there a some security element I'm missing? Or is what I'm doing ok? What would be the strongest argument against using this technique? Is there a best practice I don't get?
To be honest, I don't really see a problem. Yes, document.write is very old-school, but it is simple and universally supported; you can depend on it working the same in every browser.
For your application (writing out a HTML table with some data), I don't think a more complex solution is necessary if you're willing to assume a few small risks. Dealing with DOM mutation that works correctly across browsers is not an easy thing to get right if you're not using jQuery (et al).
The risks of document.write:
Your script must be loaded synchronously. This means a normal inline script tag (like you're already using). However, if someone gets clever and adds the async or defer attributes to your script tag (or does something fancy like appending a dynamically created script element to the head), your script will be loaded asynchronously.
This means that when your script eventually loads and calls write, the main document may have already finished loading and the document is "closed". Calling write on a closed document implicitly calls open, which completely clears the DOM – it's esentially the same as wiping the page clean and starting from scratch. You don't want that.
Because your script is loaded synchronously, you put third-party pages at the mercy of your server. If your server goes down or gets overloaded and responds slowly, every page that contain your script tag cannot finish loading until your server does respond or the browser times out the request.
The people who put your widget on their website will not be happy.
If you're confident in your uptime, then there's really no reason to change what you're doing.
The alternative is to load your script asynchronously and insert your table into the correct spot in the DOM. This means third parties would have to both insert a script snippet (either <script async src="..."> or use the dynamic script tag insertion trick. They would also need to carve out a special <div id="tablegoeshere"> for you to put your table into.
Using document.write() after loading the entire DOM do not allow you to access DOM any further.
See Why do I need to use document.write instead of DOM manipulation methods?.
You are in that case putting away a very powerfull functionnality of in web page...
Is there a some security element I'm missing?
The security risk is for them in that theirdomain.com trusting your domain's script code to not do anthing malicous. Your client script will run in the context of their domain and can do what it likes such as stealing cookies or embedding a key logger (not that you would do that of course). As long as they trust you, that is fine.
I just like to ask what the title says. The following string required into HTML script tags?
<!--
//-->
If I don't use them what would happen?
Not unless you are targeting browsers that predate the <script> element (i.e. Netscape 1 and friends). (Hint: You aren't).
If you don't use them, and a browser that old (so old it can't even cope with the HTTP Host header which is needed for sites that use virtual hosts) tries to access the site, then the content of the <script> element will be treated as text to be displayed.
Further reading: Comments and CDATA: The mysterious history of script and style in HTML
The worse thing that can happen is that your page is retrieved by a user agent that's not aware of the <script> tag and tries to parse your script block as regular HTML. JavaScript code will be handled as regular text and < symbols might interfere with the page markup. A forced example:
<script type="text/javascript">
if(a<del || a>b){
foo();
}
</script>
Lorem ipsum dolor sit amet.
... could render as ugly deleted text:
if(ab){ foo(); } Lorem ipsum dolor sit amet.
Do these obsolete user agents exists? Oh, sure they do. Please note I've carefully avoided the word "browser". The question is not who's using Mosaic nowadays. It's that a your site can be read by a poorly-written PHP-powered regexp based parser.
Should you care? Well, probably not :)
If you don't use them, a browser from the early 90's might display the source JS code instead of running it.
No, they're not required.
This habit is required for supporting really old browsers and is slightly related to including CDATA tags which should be included for validation purposes. Neither of them are required, but serve or have served their purpose as is clear from some of the more elaborate answers.
See: When is a CDATA section necessary within a script tag?
For valid HTML, your inline JavaScript should be HTML escaped.
If you were to write a script such as:
<script type="text/javascript">
document.write('<script type="text/javascript" src="http://code.jquery.com/jquery-latest.min.js"></script>');
</script>
There will be an issue, because the script contains </script> which will close the first opening script tag. Older user agents had all sorts of issues with poorly escaped JavaScript, and it was easier to tell people to use:
<script>
//<!--
//-->
</script>
Than it was to teach people to write the script as:
<script type="text/javascript">
document.write('<script type="text/javascript" src="http://code.jquery.com/jquery-latest.min.js"></script>');
</script>
Note that JS comments are used to prevent the JavaScript engine from trying to execute <!-- and -->, which might be legitimate statements (a<!--b and a-->b).
Than explain that they actually needed to turn every " to ", < to <, > to > and & to &.
The "modern" fix for this is to use a character data element, which tells the document that everything contained should be treated as literal text:
<script type="text/javascript">
/* <![CDATA[ */
/* ]] */
</script>
In this case I'm using multi-line comments so that the code isn't corrupted if it's minified to a single line (some rich text editors have done this to me in the past).
The best solution is to simply keep all HTML in .html files, all CSS in .css files and all JS in .js files. You won't ever have to worry about HTML escaping your JavaScript, and you'll be able to reuse your JS elsewhere simply by inserting a new <script>.
Google "why comment out javascript in html", first hit:
http://www.howtocreate.co.uk/tutorials/javascript/incorporate
This is not needed any more. All current browsers are aware of script tags, and how to treat their contents, since they have been part of HTML since HTML 3. Browsers that do not understand HTML 3 or scripts (these are virtually never used now) will display the script as if it was the content of the page. You can hide the script from them by commenting out your script with standard HTML comments.
99% of the time, they are no longer needed :) Unless your running some really old browser!
Commenting JavaScript code in such way may also prevents the content from indexing in search engines and may be desirable in some cases.
For example, some time ago I found a lot of "page not found" issues in the Google webmaster tools. After simple analyzing of the urls, I cleared out that Google get all path-like variables from my JS code (like "name/001"), joined them with the current url (mysite.info/staff) and tried to request the resulted url. Without success, of course.
After inserting <!-- //--> in some of JS blocks, all "page not found" issues disappeared in a matter of month or two.
If I have a userscript that I've found online, and I'd like to incorporate it into a website as a normal javascript (i.e. not userscript), how can I do that?
This seems like it would be something pretty simple but I am new to javascript and userscript, hopefully somebody can help me out.
For example, I found this userscript: "Convert UPS and FedEx Tracking Numbers to Links"...
Which will parse a page for regular expressions matching any UPS/FEDEX/USPS tracking number, and convert them to links to the respective carriers' tracking website to track that number.
This works great as a userscript, but I would like it to be automatic on the site I am working on (not require visitors to download/install a userscript).
How can I use this userscript as a regular javascript?
UserScripts are usually executed after the page DOM is loaded, to make sure that the page contents can be completely accessed. So, you need some kind of mechanism to achieve that. But this is a bit tricky since older versions of IE need special treatment.
Doing it manually would require about 30 lines of code. Libraries like jQuery offer a ready() method like so:
<script src="http://code.jquery.com/jquery-latest.min.js"></script>
<script>
$(document).ready(function () {
// put userScript here
});
</script>
It should just be a matter of linking it like any other Javascript file:
Save it as foo.js, then in your html,
<body>
<!-- body code here -->
<script src="foo.js"></script>
</body>
You can just put it in a JS file and include the file in your page.
UserScripts contain normal Javascript code, but are executed by a plugin rather than being on the page.
Alright... I've been searching for an hour now... How does one get the innerHTML of a script tag? Here is what I've been working on...
<script type="text/javascript" src="http://www.google.com" id="externalScript"></script>
<script type="text/javascript">
function getSource()
{document.getElementById('externalScript').innerHTML;
}
</script>
I've been trying to work on a way to call another domain's page source with the script tag. I've seen a working example, but cannot find it for the life of me...
You can't do that. There is no innerHTML....all you can do is pull down the file view XMLHttpRequest to get to its contents....but of course, that is limited by same-origin policy, but script tags are not. Sorry.
actually, there is a way to get the content, but it depends on the remote server letting you get the file without valid headers and still fails a lot of the time just because of those settings. using jQuery since it's the end of my day and I'm out the door....
$.get($('#externalScript').attr('src'), function(data) {
alert(data);
});
I'm guessing you want one of two things:
To make a JavaScript file global (so that other pages can call it)
To get the script that is currently in the file
Both of those can be solved by moving your script to a .js file, and then using the tag
<script src="[path-to-file]"></script>
You can't do this. It would be a massive security problem if you could.
Script content can include any number of things. Consider this: a script loaded from a URL on your bank's website might contain all sorts of things, like your account number, your balance, and other personal information. That script would be loaded by your bank's normal pages to do what they want to do.
Now, I'm an evil hacker, and I suspect you may be a customer of Biggo Bank. So on one of my own pages, I include a <script> tag for that Biggo Bank script. The script may only load if there's a valid Biggo Bank session cookie, but what if there is? What if you visit my hacker site while you're logged in to Biggo Bank in another browser tab? Now my own JavaScript code can read the contents of that script, and your money is now mine :)
You can Use Html Parsers:
jsoup » jsoup: Java HTML Parser
jsoup: Java HTML Parser
jsoup is a Java library for working with real-world HTML. It provides a very convenient API for extracting and manipulating data, using the best of DOM, CSS, and jquery-like methods.
refer this:
http://jsoup.org/