We Keep Coding

Is this vulnerable to XSS?

I know this is vulnerable as a hacker could embed an image that visits the site URL and do all sorts with the 'message' parameter:
<script>
var message = // get message parameter from URL, e.g domain.com?message=hello+there
document.write('Your message: ' + message);
</script>
...but is there any way a hacker could do anything with this (on its own without any other JS)?:
<script>
function displayMessage(message) {
document.write(message);
}
</script>
Obviously I could open a console in a browser and type anything in, but could a hacker invoke a JavaScript method somehow (with this code alone)?
I know the method could be invoked if the website also had the code at the very top, but can a method be invoked on its own?
Btw. I'm not exactly looking to do the above, it just helps me understand this.
What have I tried?
Read a lot of the docs on owasp.org
Googled terms such as “XSS - can you invoke a method”
http://excess-xss.com/
http://www.golemtechnologies.com/articles/prevent-xss#how-to-test-if-website-vulnerable-to-cross-site-scripting
Read many of the Similar Questions shown in the nav panel when typing this question

In the first code, message is an untrusted string which can contain malicious code. Parsing it as HTML may execute that code:
var message = '<img src="//" onerror="alert(\'You are pwned!\')" />';
document.write('Your message: ' + message);
The second code is different. It's just a function, it doesn't run anything by itself.
Of course, if you call it with an untrusted string, you will have the same problem than in the first one. Therefore, don't do that.
However, attackers can't call arbitrary functions. Well, if they can, it means you are already pwned, so it doesn't matter anymore. I mean, if an attacker has gained enough "privileges" to be able to call displayMessage, why bother calling it instead of calling document.write (or whatever) directly?

Script error: "Unable to get value of the property 'split': Object is null or undefined

I searched around, and couldn't find an answer to my question. I'm very new at coding, and at work, we have an application that current names that are logged in, and what they are doing.
Recently, they have changed from jquery 1.4.1 to jquery 1.8.3. Ever since then, I cannot get the results to process correctly, because of the following error;
"Unable to get value of the property 'split': Object is null or undefined"
I have the code setup to grab the results and split them;
function processAgents(xData, status) {
var avail = xData.responseText.split("|")[0];
var acw = xData.responseText.split("|")[1];
var total = xData.responseText.split("|")[2];
var breaks = xData.responseText.split("|")[3];
var pending = xData.responseText.split("|")[4];
The application is setup to open as an HTA file which opens up the PHP script.
Any help would be appreciated, please let me know if I left anything out!
Thanks!
EDIT 1
I did some more investigating, and it looks like I'm not getting data from my process request. This is how it is currently setup
function updateAgents() {
var ts1 = new Date().getTime();
$.ajax({
url: "http://SERVER/AgentSrc.php?x=" + ts1,
complete: processAgents
I'm not sure if this is processing correctly since they went to jquery 1.8.3.
EDIT 2
So after looking into it more, it doesn't appear that the script is getting the data from the server, even though I have access. If I make a local file and put the information in it, it will pull the information and split it, but if I point to the path of the file on the server, it won't get the information. But the strange thing is, if I run it using jquery 1.4.1, it pulls the data fine, but can't display it. But with 1.8.3, it doesn't allow me to pull it from the server.
thanks again!

This will give some clarity
xData.responseText.toString().split("|")[0];
(split is part of string not jQuery)

Here is a possible explanation: in earlier versions of jQuery, ajax calls returned an xmlHttpRequest (XHR) object. Recent versions return a promise (jqXHR) instead.
See this page for more details.

connecting javascript to a Web API

I am new to the web development world and I would like to be able to connect an HTML page to a web api through . and I was really not successful in this.
I followed this tutorial to be able to make this connection : http://www.asp.net/web-api/overview/getting-started-with-aspnet-web-api/tutorial-your-first-web-api
All I need is to send some inputs from an HTML page to a web api that takes these parameters and returns an object
I am using this code
$.getJSON("api/GeneratorController/setparameters/"+firstparameter+"/"+secondparameter+"/"+thirdparameter+"/"+fourthparameter+"/"+fifthparameter+"/"+sixthparameter,
function (data) {
alert(data); //never comes here
}).fail(function (jqXHR, textStatus, err) {
alert("All checks are correct, image was not generated. jqXHR = " + jqXHR.valueOf() + " textStatus=" + textStatus + " Error" + err);
});
it always goes into the fail portion , I attached the alert message that comes out of it
Any Reason why it is doing this ?
#smartmeta (I changed the typo , thanks) I followed your advice and here is the output of the alert (as expected , values that I have inserted are displayed):

Your url needs to start with your domain, not 'api/generatorcontroller/...'. If you are developing locally, something like http://localhost:[port]/api/generatorController/....
Also, webApi maps to url verbs, (get, post, put, delete..), not functions like setparameters, unless you have a [name=setparameters] above your get() function.
Also, I am pretty sure you don't have a route setup to handle the url with all those parameters. What you want to look at, as it seems your using jQuery, is jQuery.get documentation. The second example near the bottom shows where to place parameters. WebAPI will check for them in the body if they are not in the query string. so it would end up looking like:
$.getJSON("http://"+window.location.host+"/api/GeneratorController/setparameters", {parameter1: parameter1, parameter2:parameter2 ...});

Well, the first thing to check is to make sure that your server-side function is returning the values you expect. You can do this with Chrome's developer tools or with the Firebug Firefox extension, and I think IE10 has something equivalent, too. Go to the "net" tab, find the request corresponding to your API call, and take a look at what the server responded with.

Please add the line
alert("api/GeneratorController/setparameters/"+firstparemeter+"/"+secondparameter+"/"+thirdparameter+"/"+fourthparameter+"/"+fifthparameter+"/"+sixthparameter)
Then call your script and take the output of the alert into a browser. Then check if your application Handels that route.
By the way I think you have a typo. I guess it should be firstparameter.
I assume you would like to do
"api/GeneratorController?foo=Bar
But when you are new to this, I would suggest that you first try the example like it is. And After that you can start changing setails.

So I found what was the problem with my code
Two things :
1- I shouldn't use the word "Controller" when I call my API ,it should be api/Generator/...
2- the function name needs to start with "get" and not "set" since it "gets" the return value from the api
Thanks everyone!

trapping and logging "bugfoot" javascript exceptions in a meaningful way

We have had some reports of problems with our checkout whereby customers get js exceptions (we assume) so they cannot checkout.
No matter how many testbenches we use, we have failed to recreate the issues but that's the point of the exercise.
I have setup a simple error trapping function which works based around:
window.onerror = function(message, url, line, chr) {
new Request({
url: "/errorTrap.php",
data: {
m: message,
u: url,
l: line,
c: chr
},
method: "get",
onComplete: function() {
// perhaps save the rendered html source via a second POST request?
alert("done");
}
}).send();
return true;
};
Sure enough, in a single week I have now received 8 emails of trapped exceptions.
Regretfully, the checkout page is very dynamic. It contains SOME inline javascript, a lot of it is external .js files and classes and some is evaluated js through ajax responses. The length of the page differs dependent on items in the shopping basket, shipping options, address book info and so forth.
This is why seeing an exception 'Object expected' on line 253 means very little as it does not help me understand which function has triggered the exception or supply the context of the script block / source code that goes with it.
I have been thinking of doing a second XHR request that can drop the innerHTML of document.body to a ajax handler and thus supply a relative line numbering and content that may have caused the problem.
Is this the only improvement in tracing I can do? Are there any solutions for this "out there"?
Here is the jsfiddle that demos the exception handling http://www.jsfiddle.net/dimitar/8hqrY/

Well, debugging a problem is always like that. Either going there, actually seeing the issue and then tackling it with debug tools or getting evidence, guesswork, getting more evidence and so on, Sherlok Holmes-style :^)
In addition to DOM tree, you can get JS stack trace: A Javascript stacktrace in any browser.

ExtJS: autoLoad does not work in IE

Using ExtJS 2.2.1, I've got a container element which is supposed to load a piece of HTML from the server using:
autoLoad: { url: 'someurl' }
This works fine in Firefox, but for IE7 this results in a syntax error in ext-all-debug.js at line 7170:
this.decode = function(json){
return eval("(" + json + ')');
};
I fixed this by turning that function into this:
this.decode = function(json){
return eval('(function(){ return json; })()');
};
Then the autoLoad works well in both browsers, but then there's some odd bugs and besides, you really don't want to fix this in the ExtJS library as it will be unmaintainable (especially in the minified ext-all.js which is like half a megabye of Javascript on a single line).
I haven't been able to find a lot about this bug.
Variations that I've tried:
// With <script> tags around all the HTML
autoLoad: { url: 'someurl', scripts: true }
// With <script> tags around all the HTML
autoLoad: { url: 'someurl', scripts: false }
And visa versa without the <script> tags. There isn't any Javascript in the HTML either, but it should be possible, because eventually we will use Javascript inside the returned HTML.
The problem isn't in the HTML because even with the simplest possible HTML, the error is the same.
UPDATE - Response to donovan:
The simplest case where this is used is this one:
changeRolesForm = new Ext.Panel({
height: 600,
items: [{ autoScroll: true, autoLoad: WMS.Routing.Route("GetRolesList", "User") + '?userID=' + id}]
});
There is no datastore involved here. The response-type is also text\html, not json, so that can't be confusing it either. And as said, it's working just fine in Firefox, and in Firefox, it also executes the same eval function, but without the error. So it's not like Firefox follows a different path of execution, it's the same, but without the error on eval.

Check your JSON. FF allow trailing commas in JSON objects while IE does not. e.g.
{foo:'bar',baz:'boz',}
would work in FF but in IE it would throw a syntax error. In order for there to not be a syntax error the JSON would need to be:
{foo:'bar',baz:'boz'}

I located the source of the problem and it was indeed not with ExtJS. There was a section in the application that listened to the Ext.Ajax 'requestcomplete' event and tried decoding the response.responseText to json, even if the response was HTML (which it only is in one or two cases). IE was not amused by this.

If you're autoLoad'ing into a Panel or Element then a JSON decode shouldn't even be involved in the process. UpdateManager just defers to Ext.Element.update(..) which takes a string of html.
The only reason I can think that your response would be parsed as JSON is if you were using a JSONStore to request it - what are you using?
You should be able to do something simple like this:
var panel = new Ext.Panel({
autoLoad: 'someurl' // this is the short form, you can still use the object config
});
OR
var element = Ext.get('element id').update({
url: 'someurl'
});
Response to Update:
That looks correct as long as something weird isn't happening with the WMS.Routing.Route(...) method. I'm actually currently working on an ExtJS application myself so I was able to quickly test some different server responses and couldn't reproduce your problem. I've also relooked at the ExtJS 2.2.1 sources and still see nothing in the related Element update and UpdateManager that would make the call to Ext.util.JSON.decode(...) that you're seeing.
I'm imagining that its from an unrelated AJAX request in another part of your application. If you're not already, I would use firebug / firebug lite to help debug this - specifically try to get a stack trace to make sure the source of your problem really is this autoLoad.

I had the same problem, excuse my english, i'm from Mejico, i hope I can help… my problem was triggered when I submit a Form to login, my PHP returns a JSON with the response in case of failure like this:
$respuesta = "{success: false, msgError: 'El usuario o contraseña son incorrectos'}";
but I wasn't send a resposne when it success, well when it has a true success, then the ExtJS it was trying to decode my JSON response, but there was nothing to decode, i guess that was, in my case again, the problem… I solved just sending back a response for the true succes, FF, Chrome, Safari, dont catch the problem, but Opera and IE8 does… I hope I help someone, goodbye

I don't know what the problem is, but I wanted to point out that your "fix" makes it simply return the json as a string instead of an eval'd object, so of course there is no error anymore -- you removed the functionality. It could just as simply be:
this.decode = function(json){
return json;
}
Generally speaking, random errors like this do not usually indicate a bug in Ext, especially not in functions used as commonly as Ext.decode. I would guess that either there is something in the JSON that IE does not like that other browsers ignore, or more likely, there is something unexpected going on in your app that is not obvious from your description. Have you tried inspecting your request log in Firebug to see what the JSON actually looks like? Have you tried getting the result of your Route call into a variable first to verify its contents before populating the panel? Also, try setting the "break on all errors" option in Firebug to true -- a lot of times when you get a random function from Ext at the top of your stack trace, the culprit is actually some application code that you weren't expecting.