Security via JavaScript

Daniel15

I encountered this on a website I went to... Another example of security via JavaScript.
Client-side banning? Via JavaScript? Brillant! What could possibly go wrong? rolls eyes

<script type="text/javascript"> //Enter list of banned ips, each separated with a comma: var bannedips=["23.23.23.23", "11.11.11.11"] var ip = '' var handleips=bannedips.join("|") handleips=new RegExp(handleips, "i") if (ip.search(handleips)!=-1){ alert("Your IP has been banned from this site. Redirecting...") window.location.replace("http://www.google.com") } </script>(additionally, note the non-working SSI statement).

dhromed

Ah, yes, fundamental cluelessness at its best.

GuntherVB

I've just... fiddled.. with a webshop that did almost everything via javascript, including some security 'features'.

An example:

SendLoginData

if Response.Code = OK then LoggedIn

elseif Response.Code = NOTOK then ShowUserAMessage

elseif Response.Code = CHANGE then RedirectTo changePassword.asp

Like no-one would take a look at the code to find out the password page. Now you can change the password for any user by guessing the userID (which is easy to do since the javascript login system tells you "UserID Incorrect" or "Password incorrect").

JOY

DaveK1

@Daniel15 said:

Client-side banning? Via JavaScript? Brillant! What could possibly go wrong? *rolls eyes*
var ip = ''(additionally, note the non-working SSI statement).

That should have given you the clue you needed. It's not an attempt to implement client-side banning, it's an attempt to implement server side banning. I think they just forgot the RUNAT attribute.

rbowes

Well, on the plus side, it might give you a handy dandy list of IPs to ban from your own site.

Daniel15

@DaveK said:

@Daniel15 said:
Client-side banning? Via JavaScript? Brillant! What could possibly go wrong? rolls eyes
var ip = ''(additionally, note the non-working SSI statement).

That should have given you the clue you needed. It's not an attempt to implement client-side banning, it's an attempt to implement server side banning. I think they just forgot the RUNAT attribute.

I didn't think that JavaScript could run on a server? Even if it does, the alert() wouldn't really make sense in that situation
Edit: I think the runat thing is a ASP thing? If so, this site was on a cPanel-based server, so it was Linux, not Windows.

Daniel15

I've just... fiddled.. with a webshop that did almost everything via javascript, including some security 'features'.

Haha :P
Does the shop even work correctly with Javascript disabled? Will it even load?

(I would have added this to my other reply but it says the edit timeout has expired. I mean seriously, why would a forum have an edit time limitation? That's just crazy

dhromed

@GuntherVB said:

I've just... fiddled.. with a webshop that did almost everything via javascript, including some security 'features'.
An example:
SendLoginData
if Response.Code = OK then LoggedIn
elseif Response.Code = NOTOK then ShowUserAMessage
elseif Response.Code = CHANGE then RedirectTo changePassword.asp

Sir,

Your example is in VBscript.

Daniel15

@dhromed said:

@GuntherVB said:
I've just... fiddled.. with a webshop that did almost everything via javascript, including some security 'features'.
An example:
SendLoginData
if Response.Code = OK then LoggedIn
elseif Response.Code = NOTOK then ShowUserAMessage
elseif Response.Code = CHANGE then RedirectTo changePassword.asp
Sir,
Your example is in VBscript.

I think his example was just psuedocode ;)

Daniel_Beardsmore

@DaveK said:

It's not an attempt to implement client-side banning, it's an attempt to implement server side banning. I think they just forgot the RUNAT attribute.

Even though they implemented redirect via window.location.replace();? Why would anyone be using SSI to inject the remote IP inside JScript code inside ASP? I think the original assertion stands.

IHateEverybody

If this thing is blocking by IP, then anyone behind NAT is safe because their IP should always be a non-routed address. Their external IP could very well be on the ban list, but their browser evaluating the javascript has no idea about that external IP. Alternatively, everyone behind NAT could get screwed simultaneously if the site added the non-routed addresses to their ban list.

Daniel15

@IHateEverybody said:

If this thing is blocking by IP, then anyone behind NAT is safe because their IP should always be a non-routed address. Their external IP could very well be on the ban list, but their browser evaluating the javascript has no idea about that external IP. Alternatively, everyone behind NAT could get screwed simultaneously if the site added the non-routed addresses to their ban list.

Wow, I didn't think of that... That explains why it uses a SSI function to get the IP address. Of course, the "Web 2.0" approach would be to use AJAX to call a script that returns the client's IP address, then grab the latest ban list via AJAX :D

Seriously though, Apache's mod_access is way easier (not to mention it's one of the proper, server-side ways to do banning):
Order allow,deny Allow from all Deny from 23.23.23.23 Deny from 11.11.11.11
Speaking of this, I'd still be screwed if they banned "my" IP address... My ISP uses a transparent proxy, so "my" IP is actually the IP of their transparent proxy (202.7.176.130 to 202.7.176.138 for Melbourne). Of course, this makes it easy to bypass the ban — Just use a different proxy. The actual solution would be to use the X_FORWARDED_FOR header (which contains my real IP), but that gives users another way to bypass bans (send a fake header).

PSWorx

As for an unrelated, minor WTF, I like how he implemented the actual ban checking. I guess if all you have is a regex, everything looks like a string...

Daniel_Beardsmore

@Daniel15 said:

Speaking of this, I'd still be screwed if they banned "my" IP address... My ISP uses a transparent proxy, so "my" IP is actually the IP of their transparent proxy.

Hahaha sucks to be you! My ISP has only recently let go of that absurd scheme, probably when they got bought out. Now, RapidShare works, and SourceForge stops kicking me out for security reasons (mismatched port 80 and 443 IPs) and I don't get banned randomly from sites I've not even been to lately. Then again, the Web has been pretty flaky since that point, their network probably can't handle the strain of living without cache proxies. It seems to have sorted itself out now though.

Thief

You can easily have a transparent caching "router" proxy thing, that would cache the client's request, route it onwards if it couldn't serve it or reply if it could.

You wouldn't get it showing with the wrong IP because it would send packets as the client it's working for, not as itself.