I will probably make a few mods and hacks for the CMS as it’s a great project with a nice style and ethos.
This simple modification will place a captcha on the registration page to help prevent spam, bots, and fake registrations.

After about 10 minutes of setting the WebWoW CMS I started to get bot registrations indicated by the spammy usernames and lack of activity.
Hopefully this will be of use to someone

Only two files edits are required so it shouldn’t take more than 5 minutes to implement.

WebWoW Registration Captcha Mod

Please remember to backup any files before editing!

1 – Open: engine/func/session.php

  1a. Find: (about line 324)

        Change To:

 1b. Find: (about line 397)

        Add BELOW:

2 – Open: engine/modules/register.php

 2a. Find: (about line 26)

        Replace with:

 2b. Find: (about line 109)

        Add BELOW:

 3. Upload: /captcha/ folder to your site root

            Download Captcha Files

Please let me know if you find any errors or have any problems.

This short article details how the attack works.

Enabling the passcode lock on your iPhone is, for now, not enough to prevent someone using your device and adding to your bill!
This should worry you if your concerned about iPhone security.

How the vulnerability works

1. Hit “emergency call”
2. Type in a random number.
3. Hit the call button.
4. Shortly after, press the lock button on top of the phone.
4.1 That’s it! Your now an uber l33t haxor -_-

This isn’t a major security risk (yet) as full access to the phone’s operations isn’t granted, but it does point out yet another fundamental flaw in Apple’s iPhone software.
Let’s hope the team working on security for iOS have a good look through the crappy code their producing to iron out any more surprises.

The video below shows how simple and quick this can be.

There is no fix for this hack yet and will probably only be patched on the next iOS update, 4.2.
If you use an iPhone with iOS version 4.1 the only real way to keep it safe is to be careful who you let use it.

This article covers what the risks are and how to prevent this type of attack…

The latest wave of iPhone attacks have revolved around one primary issue: Jail broken iPhones.
A simple explanation of Jail breaking is quoted from Wikipedia

Jailbreaking is a process that allows iPhone and iPod Touch users to run unofficial code on their devices bypassing Apple’s official distribution mechanism, the App Store. Once jailbroken, iPhone users are able to download many applications previously unavailable through the App Store via unofficial installers such as Cydia, Rock App, Icy, and Installer. Cydia is preferred by the community, while Rock App has a small catalog of mainly paid apps. Icy and Installer are officially unsupported by their developers and rarely used. Cydia founder Jay Freeman estimates that 4 million (out of 40 million) iPods and iPhones are jailbroken.[1] A jailbroken iPhone or iPod Touch is still able to use and update apps downloaded and purchased from Apple’s official App Store.

Jailbreaking is distinct from SIM unlocking, which is the process by which a mobile device is made compatible with telephone networks with which it was not specifically licensed to be used. Jailbreaking, while not illegal, gives a user the option to install cracked (pirated,) apps, which is illegal. Jailbreaking voids Apple’s warranty on the device.

The iPhone trojan attacks started as silly “Rick Rolling” hacks, but quickly turned into fully fledged bank phishing software!

These trojans will only effect you if you have Jail broken your iPhone to work with unofficial software and games and have not changed the default SSH account created by “unlocking” your iPhone.

The most harmful trojan is currently known as “iPhone firmware 1.1.3 prep”, or “113 prep”.
It is written in Python and allows hackers access to the victim’s device from a computer running Windows, OSX/Unix and Linux. Nearly any data stored on the iPhone can be stolen and this trojan allows them to do just about anything with the stolen data.

Just think if this malware accessed your messages, bank account, paypal account, or other apps containing sensitive information.
It could very easily turn nasty.

Below is a simple guide on how to prevent this happening…

Secure Your iPhone’s SSH Password!

Here’s how to change default SSH password on a jailbroken iPhone :

1. Make sure you have Cydia installed on your jailbroken device. If you don’t already have MobileTerminal installed, launch Cydia and tap the ‘Search’ tab in the bottom navigation bar.

3. Navigate to the newly installed ‘MobileTerminal’ application and tap to open.

4. In MobileTerminal, type ’su root’ and tap return. It will ask you for a password, enter “alpine” and tap return again.

5. Now, type “passwd” and then tap return. Type in a new password such as “secret” (but not a word in the dictionary!) and tap return. Retype the new password to confirm and then tap return one last time to change the password.

6. Now, your SSH password will be changed and your device will be protected against any future hacks that use SSH to access your device.

There a are some simple steps which you can take to prevent most of these.
This article will go over some of the fundamental XSS attacks and how to stop them.

As of 2007, cross-site scripting carried out on websites were roughly 80% of all documented security vulnerabilities. Often during an attack “everything looks fine” to the end-user who may be subject to unauthorized access, theft of sensitive data, and financial loss.

Cross-site scripting (XSS) is, in short, a way of injecting code by a malicious web user. The code can be used for anything from displaying a persistent pop-up or crashing the browser, to including remote files to run scripts and steal cookies!

What code do I need to sanitize?

What will this magical code look like?
That’s an easy question to avoid as there are many ways to mess with a website that gives permission to post raw code! Not all XSS attacks will work on all websites or even all broswers. So you may see someone testing with strange looking code before you see some, if any, form of attack.

For this reason, I think it’s best to implement some form of BBCode system.
But more on that later…

A few common XSS codes could include…

Most of these examples will just show an annoying pop-up saying “XSS”, but could be used for more malicious purposes.

If any of the above XSS examples are allowed to be displayed as output from your page, you have could have serious problems!

As mentioned above, there are MANY ways to abuse a website that doesn’t check what your posting or submitting.
It may seem like a good idea to ask for visitors comments or asking for an email address for news subscriptions, but it’s worth checking what content will be displayed when the form is submitted.

How can I prevent XSS attacks?

Any code that can be submitted by a user should be validated or filtered in someway. Steps need to be taken to ensure malicious code can’t be executed on output.

Non-crucial pages like a confirmation page don’t need full validation. But, if a feedback form is allowed to go unchecked it could mean a cookie stealer gets injected and your customers details get stolen!

Generally speaking, it’s best to validate of any forms or inputted data submitted to your web site. Validating the data on input (rather than output) not only helps prevent possible attacks more effectively, but also makes sure only clean code gets entered into the database.

There are other benefits to cleaning up the code before it gets entered into the database. One great advantage is clean output to an administration section.

Let’s take my Free Online Arcade as an example:
If I decided to ask for visitors to submit games to the website, I could just use a simple textbox to ask for the embeddable code to be entered. If the submitted content wasn’t validated in some way an attacker could inject a cookie stealer to hijack the administrators session! Flash code would not even be required if no form of validation is used, so I could just use embed a cookie stealer and a game together.

In an idea world, ever input field would be validated to ensure clean output. But that can be very time consuming.

When accepting data from a user, any data at all, it should be sanitized before making its way to your database.
…..
We’ll scan through the input, searching for anything that shouldn’t be there, like html code, <script> tags, etc
…..
To use, we simply pass any input to the function. The function works on single strings, as well as deep arrays.

Denham Coote’s Blog has a great article on Stripping out malicious code for PHP, which is easy to implement and very effective.

Whenever you make a form you should not leave it alone without any form validation. Why? Because there is no guarantee that the input is correct and processing incorrect input values can make your application give unpredictable result.

Form Validation With PHP covers the subject in a little more detail. The article includes full source code and examples.

Closing Notes

To sum it all up… Trust No One!
Try to validate any code that will be submitted to the database or displayed on the website, even if only to remove the script tag.

In my opinion it’s a good idea to try and think like a hacker. Spam test your site before putting any changes in place. Try to execute some annoying javascript. Could you include remote javascript files? Will malformed tags allow injection?

If you can do it, the hackers can generally do worse!

to the end of any URL that is a PHP page, you will see a funny picture on most servers. Also on April 1st (April Fool’s Day), the picture will replace the PHP logo on any phpinfo() page. If the PHP directive expose_php is set to be “off” in php.ini, then the PHP eggs will not show, but it is “on” by default, and many webhosting servers do not change it.

If you see such a URL in your website logs, it may be because someone is trying to determine if your server is running PHP and attempting to discover weaknesses in your system. By setting expose_php = off in the php.ini configuration file, you will reduce the amount of information available to them. If the PHP easteregg is active (the URL shows the image), then scanning the website with Nitko web server scanner will give the warning message, “PHP reveals potentially sensitive information via certain HTTP requests which contain specific QUERY strings.”

These are the four QUERY strings you can add to the end of a PHP web page to view a (somewhat) hidden image or web page:

(1)

This one is the most interesting, and displays an “easter egg” image of either a rabbit in a house, a brown dog in the grass, a black Scottish Terrier dog, a sloppy child-crayon-colored php logo, or a guy with breadsticks (looks like pencils or french fries) sticking out of his mouth like a walrus. The original dog was Stig Bakken’s (Stig is one of the PHP developers); the newer dog is Zeev Suraski’s dog (the link goes to his blog entry about the dog, called Scotch or Scottie, that died August 30, 2005); and the guy is Thies Arntzen (the logo image was taken from a picture from the PHP Developers’ Meeting that the PHP Group held in January 2000). The five images are shown below. Anyone know whose rabbit it is, or more details on these? The black dog, colored logo, and rabbit pictures are 10 pixels shorter than the other two images.

(2)

This is used by the phpinfo function to display the PHP logo, but works on other PHP pages.

(3)

This is used by the phpinfo() function to display the Zend logo, but also works on other PHP-parsed pages.

(4)

This displays the PHP development credits, and is linked to from any phpinfo() page with text “PHP Credits”.

The only truly hidden image is the first one above. The other three are called from the web page produced by the phpinfo() function.

For the first code above, other online sources claim it displays a rabbit in PHP versions 5.0 and 5.01, a dog in 4.3.0 and higher (below 5.0), and the funny PHP coder guy in PHP versions 4.0 through 4.2.3. Below are the images I saw for these PHP versions:

PHPCODER GUY WITH BREADSTICKS (Thies C. Arntzen):
PHP Version 4.0.1pl2
PHP Version 4.1.2 *
PHP Version 4.2.2 *

BROWN DOG IN GRASS:
PHP4u Version 3.0, Based on PHP-4.3.2
PHP Version 4.3.2
PHP Version 4.3.3
PHP Version 4.3.8
PHP Version 4.3.9
PHP Version 4.3.10

BLACK SCOTTISH TERRIER DOG:
PHP Version 4.3.11
PHP Version 4.4.0
PHP Version 4.4.1
PHP Version 4.4.2
PHP Version 4.4.3
PHP Version 4.4.4
PHP Version 5.0.5-2ubuntu1.1
PHP Version 5.0.5-pl3-gentoo
PHP Version 5.1.0
PHP Version 5.1.2

RABBIT:
PHP Version 4.3.1 *
PHP Version 5.0.0 *
PHP Version 5.0.3 *

COLORED PHP LOGO:
PHP Version 5.1.4
PHP Version 5.2.0

The first code above, ?=PHPE9568F36-D428-11d2-A769-00AA001ACF42, is returned by the hidden function (undocumented in the php.net online manual) php_egg_logo_guid(). PHP_EGG_LOGO_GUID is defined as a preprocessor macro in php-src/ext/standard/info.h, line 54, and referenced in 3 files:

php-src/ext/standard/info.c (lines 988 and 1032)
php-src/ext/standard/info.h (line 54)
php-src/main/php_logos.c (line 59).

Below are the four codes’ definitions in the php source within php-source/ext/standard/info.h (lines 53 to 56):

This latest vulnerability not only has severe implications for many web masters, designers and programmers, but also affects routing servers and any system with TCP stack processes exposed to the outside world.

After the latest DNS poisoning vulnerability, webmasters seem on edge about how insecure the very foundations of the internet are (mainly due to being created before security was even thought of).

Sockstress is the name of the tool created by Outpost24, which they are still testing before releasing it. They have, however, walked through how the attack could be achieved in great detail. Some security experts have showed concern over how they handled the information released.

The sockstress attack seems to be limited to the TCP stack, but mixes several techniques to allow a very low-bandwidth hacker to deplete local resources (memory, swap file and even kernel file abuse). Just a few packets a second and a little amount of time are needed to take down a server. As little as nine packets and a few minutes are all that is suggested to be needed!

Lack of timing of the TCP/IP stack and, more specifically, kernel’s response seems to be the most deciding factor. A “Badly designed TCP stack” is referred to and after the 3-way handshake (syn cookie verification and acknowledgment) has completed, resources can be exploited!…
“The worst thing we ever had happen, was, we had Windows reboot and say ‘Operating system not found’”

In theory, a syn cookie validation process could be cycled. Sending for verification and acknowledgment, then a “no buffer space” response could be sent from the attackers end. This would force the target to allocate more resources to the attackers cycled process, with severe consequences.
Please bear in mind that this is not a syn packet attack attack! (the magic happens after the syn ack)

This can result in a denial of service (Dos) by TCP servers (www, ftp, tftp, smtp, pop, etc.) running on Windows, Linux, BSD, certain routing servers, and other Internet applications and protocols!

An excerpt from Outpost24′s website, claims:

Outpost24′s Senior Security Researcher, Jack C. Louis has discovered a generic issue that affects the availability of TCP services. This issue could be used to create a Denial of Service attack. Vendors have been notified. Details are not available to the public at this point, but will be disclosed at an appropriate future date.

Jack C. Louis, along with Outpost24′s Chief Security Officer Robert E. Lee, will be speaking at the T2 conference in Helsinki, Finland on October 16 – 17.

You can read more about the Sock stress talks here:
T2 Schedule or T2′s 08 Conference.

I want to know if there is anyone who can write a program that performs the operation described in this audio podcast.

http://debeveiligingsupdate.nl/audio/bevupd_0003.mp3

Please note, that the English portion of the audio starts about 4 minutes into the segment.
This program must be testable prior to paying for it.

Get A Freelancer has a project asking for the tools creation. How long until someone makes it public?

Podcast Downloads

You can listen to the security podcast in various formats. The Sockstress MP3 files are listed below:

The wonderful guys at GRC (proud Twit army addict myself) have have hosted the interview, just in case the original goes down.
Thanks Steve!
Entire Interview
44 min, 10 sec – 128 kbps – 41.1 MB
Entire Interview
44 min, 10 sec – 16 kbps – 5.3 MB
Trimmed Interview
38 min, 59 sec – 64 kbps – 18.7 MB
Trimmed Interview
38 min, 59 sec – 16 kbps – 4.7 MB

A full transcript is available from CurbRisk.com :
Outpost24′s TCP – Denial Of Service vulnerability interview transcript

At time of posting, there is currently no known work around or fix for this issue. The authors seem to be white hat and want to help vendors resolve the issues. But, like the rest of us, know the internet has a long way to go before being secure.

Sockstress has now also been entered into the NIST CVE database. The list of affected platforms is staggering!

It is widely accepted that “the community” prefers to find workarounds for the flawed foundations of the internet and associated protocols. But would it not be better if, knowing as much about security as we do now, the internet was written from the ground up?
Yes, it is impossible. But I think it would be the only way to make serious, major exploits like this and the recent DNS poisoning exploits avoidable.

As security online increases and encourages secure passwords, they also get harder to remember.
As a result of this, many of us have files on our hard drive / flash drive / cds etc containing our login details and other sensitive information.

There are many reasons why this is a bad idea. The latest to grab the attention of the media is related to the new powers given to US Customs and Border Patrol, allowing any suspicious electrical device to be search and / or seized!…..

Since 9/11, CBP agents have been searching and seizing laptops, digital cameras, cellphones and other electronic devices at the border, without search warrants, or probable cause. CBP agents can subject these devices to extensive forensic analysis, according to the courts.

Maria Udy, a UK citizen working for a US global marketing firm, had her company laptop seized by a federal agent prior to flying from Dulles International to London, in December, 2006. The Washington Post reports Udy said the agent told her he had a “security concern” with her. Fourteen months later, Udy’s laptop had not been returned, nor had she been able to find out what happened to it.

[ Excerpt From Tripso.com]

I would feel a lot better knowing my files where secured, if I were to lose my laptop or removable storage.

There are a few ways to hide files on your computer without too much effort.

In this example we will hide a text message inside a picture. We have choose for this tutorial a text file named Secret.txt and a picture firefox.jpg.

1. Move your files you want to combine in a new folder, in our case C:\Hidden.

2. Add the file you want to hide into a new RAR archive (in our example named Secret.txt.rar).

3. WinRar created the archive in the folder where our files are located.

4. Open Command Prompt (Start -> Run…, type cmd and press Enter).

5. Go to the folder where your files are located, in this case C:\Hidden by using the cd command.

6. Now type copy /b firefox.jpg + secret.txt.rar helpero.jpg where firefox.jpg is the original picture, secret.txt.rar is the file that will be hidden, and helpero.jpg is the file which contains both.

7. If you open helpero.jpg you will see the firefox.jpg image.

8. Try opening the file with WinRar (select All files).

9. Now you can see the text file that is hidden in the picture.

Using this method, you can “hide” any rar file (or other file, for that matter) inside the picture. It will also retain the preview and other standard picture file associations.

This won’t stop a major forensic examination, but should stop the casual user from finding your most personnel login details!

But guess what… At the end of the flash game you can optionally submit your score to the highscore server, which results in a POST to the file submithigh.php with several parameters, one parameter saying score=XXXX. And of course you can submit whatever score you want. So now I lead the highscore with 10000 of about 900 possible points. I set it that high to ensure that the guys at the ISP will realize that this is faked, but imagine I had just increased the current highscore by 10. I seriously doubt anyone would have noticed and I would have won the competition without even decompiling the flash.

[ Original Post From php-security.org ]

======
Even simple mistakes can cause a lot of trouble.
Think if all the top scores on every game game were hacked to show obscene comments!
It’s best to try and think like a hacker when creating public content

JavaScript has its own security model, but this is not designed to protect the Web site owner or the data passed between the browser and the server. The security model is designed to protect the user from malicious Web sites, and as a result, it enforces strict limits on what the page author is allowed to do. They may have control over their own page inside the browser, but that is where their abilities end.

• JavaScripts cannot read or write files on users’ computers. They cannot create files on the server (except by communicating with a server side script that creates files for them). The only thing they can store on the user’s computer are cookies.
• They are allowed to interact with other pages in a frameset, if those frames originate from the same Web site, but not if they originate from another Web site (the postMessage method from HTML 5 does safely extend this capability, but I will not cover that here). Some browsers will even treat different port numbers on the same server as a different Web site.
• JavaScript cannot be used to set the value attribute of a file input, and will not be allowed to use them to upload files without permission.
• JavaScript cannot read what locations a user has visited by reading them from the location object, although it can tell the browser to jump back or forward any number of steps through the browser history. It cannot see what other Web pages the user has open.
• JavaScript cannot access the cookies or variables from other sites.
• It cannot see when the user interacts with other programs, or other parts of the browser window.
• It cannot open windows out of sight from the user or too small for the user to see, and in most browsers, it cannot close windows that it did not open.

Most people who want to know about security with JavaScript are interested in producing password protected pages or sending encrypted data to or from the user’s computer. For true security, use SSL/TLS (HTTPS) and put all of your checks on the server. You could also use a security lockout if too many false attempts are made, preventing brute force cracks. JavaScript cannot replace this functionality. The problem lies in the fact that if a person can read what you are sending over the internet, they can also rewrite it. So when you think you are filling in a password to access a protected page, they have changed it so that you are actually filling in a password that will be sent to them. This requires SSL to be sure that you are protected. Still, this tutorial is about JavaScript, so I will now show you what can and cannot be done with JavaScript.

Protecting the source of your scripts

Oh dear. This is just not possible. Many people make futile attempts to do so, but to be honest, there is no point in trying. In fact, in many developers’ opinions, there is no such thing as copyright with JavaScript, although it is theoretically possible. The point with copyright and patents is that you can only copyright or patent something completely new, a new innovation, something that has not been done or written before. You can almost guarantee that nothing you do with JavaScript will be a new innovation or even newly written. Someone will have done it before, almost certainly using the exact same algorithm with just a few variable names changed. JavaScript is just not designed for innovative programming since it just uses APIs designed by someone else to do what you are doing, and they already came up with it before you in order to invent the API. Even if you write something in a ‘new’ way, it will still be doing something that has already been done, and if you did attempt to take things too far and take the matter to court, you would just be laughed back out of it again.

As for protecting what you send, JavaScript is passed in text, not compiled to a binary first, so the code is always visible. How can you stop people seeing the source when you are sending the source to each viewer? Let me walk through the problem.

If the source of the JavaScript is held in the page you are viewing, a simple ‘view source’ will show you the script. Looking in the browser’s cache will show the scripts that are in header files. Of course you need to check the source first to find the name of the header file.

Many developers have spotted the fact that both of these methods require the ‘view source’ to be available, so they prevent the viewer from viewing the source. They do this by preventing the context menu from appearing when the user right clicks and by removing menus by using window.open etc. Believe me, both of these are useless. You cannot stop right clicks in Opera, Safari, OmniWeb or iCab like you can in other browsers. So some people try to prevent these browsers from viewing the page by using browser sniffing. This is equally uneffective. All the viewer has to do is swich off script when they get to the page, or view the source of previous pages to find the location of the protected page. In adition, Opera, Mozilla/Firefox and Internet Explorer are all capable of running user scripts that allow the user to override restrictions made by the page.

Some people even try to make sure that the page is only delivered if a referrer header is sent to make sure that the user came from the right page, and is not attempting to type in a location manually. So the user can use Curl, a program that allows them to request a page with referrer header, cookies, form fields etc., and save the download to a text file.

Some people try to encode the script using charCodeAt or escape, but as the decoding technique is provided in the page, only simple modifications are required to make the script appear in text, not as embedded script. I have seen one set of scripts that have been ‘protected’ by changing their variable names to completely incomprehensible names, and adding several redundant lines of incompressible code and removing all redundant spaces and linebreaks. It does not take too much work to turn this back into understandable code.

You may want to protect your code, but it simply is not possible. Someone who is determined will be able to find it out.

Password protecting a file

It is best to do this with a server side script, and an encrypted connection. But since this is JavaScript …

Take the following for example. I want to only allow someone to access my page if they put in the correct password. I want to provide a box for them to write it, and then I want to test if it is correct. If it is, I let them view the page. The problem is that in the source of the page, I have to write the password in the script to test what they have written. For example:

As described in the above section, you cannot protect the source of a page, especially from someone who is really determined. There is no point in trying. Once a user managed to see the source, they could see the password or the URL in plain text, or encoded, but again, that is easy to break.

For simple security, try this technique. Name the file to be protected whateverYourPasswordIs.html and make sure there is an index.html file in the same directory. Now use the following:

The problem with this technique is that the page is still passed in plain text across the Internet, as is the name of the page that you send. If anyone is snooping at data packets on the Internet, they can retrieve the page’s contents. In many places, packet snooping is illegal, but that does not mean that no-one does it.

This protection technique is known as security by obscurity, in other words, it is only secure because no-one knows it is there. If someone was determined, they would find it.

As a more complicated solution, try creating your own encryption technique that uses a password as an encryption key. Encrypt the contents of the file. As the page loads, use window.prompt to ask the user for a key. Try decrypting the page with their key, using document.write to write the page. If your technique is good enough, wrong passwords would only produce an incomprehensible output. With this technique, the password is never transmitted over the internet in plain text, and neither is the content. This technique could be cracked by brute force, trying every possible password until something works. Better passwords and encryption algorithms will help, but if someone was determined, they would break it. One of my readers has submitted a script to do this based on RC4 and Base64.

I have used both of these techniques.

Encrypting data before it is sent to you

Normally, this cannot be done with JavaScript using the Internet alone. You can encrypt text at the user’s end and unencrypt it at your end. The problem is that the user has to encrypt it with a password that you know so that you can unencrypt it. They would have to tell you by telephone or post. Alternatively, you could put the password in the source of the page and get the function to encrypt using that key. But this password would have to be sent over the internet in plain text. Even if you did encode it, it would not be too much work for a snooper to crack it. In fact, the encryption could even be broken with brute force techniques. So what do you do?

The best possible technique would be to create a symmetric encryption key using a twin public/private key pair as with techniques such as Diffie-Hellman or SSL, or use an asymetric public/private key pair and encryption technique as with PGP or RSA. The problem is that in order to prevent brute force cracking techniques, these require the browser to handle numbers as high as 2×10600 or higher. JavaScript is just not natively capable of working with numbers as high as this. As yet, I have found no solution to this, although on http://shop-js.sourceforge.net/ there is an algorithm for emulating large number handling, and an example of JavaScript powered RSA. The technique seems to work and takes only a few seconds to create keys, by using complex mathematics and algorithms (look at the source of crypto.js) to emulate large number handling.

Even so, if doing the equivalent of RSA (etc.), it is still not possible for the user to verify your identity as with SSL certificates, so it would be possible for a third party to inject their own code and have the information sent to them instead, without the user’s knowledge. For the best security, stick to real SSL.

Protecting your email address

This is one of the very useful things that JavaScript can do. For those that don’t understand the problem, I will summarise. Search engines ‘crawl’ the Internet, following the links in pages and requesting other ones so that they can add the pages to their search databases. Using the same technology, spammers crawl the Internet looking for email addresses, whether in mailto: links or just written on the page. These email harvesters are one of the most annoying uses of otherwise useful technologies.

Simply writing your email address on any web page (through newsgroup postings etc) can leave you flooded with unsolicited emails. Many people fall into the trap of replying to these emails asking to be removed from the mailing list, and succeed only in confirming that their email address is valid. The problem is that you may actually want your email address on the page, or a link that automatically opens up a new email to you. There are a couple of steps you can take to prevent the problems with unsolicited emails:

• Use a throw-away email address like a yahoo or hotmail account when posting to newsgroups, signing online guestbooks, or writing your email address on your Web pages. That way, when you start to get too much spam on that email address, you can just dispose of that email account, and get a new one.
• If you can, tell your email client (program) not to send read-confirmations when you read your emails. This way your email client does not automatically confirm your email address.
• Be careful when setting up auto-replies.
• When you post your email address, change it to read something like myName@REMOVE_THISmydomain.com or myName(replace with @ symbol)mydomain.com and hope that anyone who legitimately replies to it works out what they need to do to turn it back into a proper email address. The problem is that not all of them understand this, and don’t understand why the email adress does not just work. So, you can try the next point as well:
• Use JavaScript. How? Read on!

Using JavaScript to write your email address

I have never heard of an email harvester that is clever enough to interpret JavaScript. All they can do is read the text that makes up the page. So if you write your email address with JavaScript, they will not be able to read it. Remember that if you write the email address as a single word, even in the JavaScript, they may still interpret it as an email address, so it helps to break it up a little:

You can also use a mailto link:

You could even use a combination of both:

There is, however, a problem with this approach. It relies on your viewers having JavaScript enabled. Many of your more web-aware viewers will not. In my case, these are often likely to be people who I want to contact me. Fortunately, these viewers are the ones who are likely to understand what to change if you tell them to as I have showed above (in the bullet points). So, you can use a combination of both approaches:

You have three options if you have total control over the server…

1. Detect proxies and block them on firewall/mod_security level
2. (1) Detect them via PHP and block them via .htaccess
3. (2) Detect and block them via .htaccess (new method added!)

01Since most people use shared hosting, number 3 is the best option unless you feel like manually banning 600 ips from /

So, just put this litle code at the top of all your main PHP files, and it will consume little to no resources.

Break down:

HTTP_X_FORWARDED_FOR: When a proxy connects to a site, it sends Forwaded-For: YourIPHere, unless it’s an elite proxy. People that don’t use proxies have no http_x_forwaded_for so that’s a dead easy way to spot them.

HTTP_USER_AGENT: This script checks and make sure the user DOES send a user agent. Most DDoSing programs don’t have a User-Agent attribute where as all internet browsers do =) Another easy spot on.

HTTP_VIA: HTTP_VIA pretty much sends what kind of proxy server it’s using, ie squid/squidX.

Info:

Most DDoSing programs hit http://site.com, not http://site.com/page.php. When the program connects to site.com/, the index file is loaded. index.php in most forums.

So, if you put that code in index.php, the first line of it, then you’ll barely feel any effects of proxy DDoSing.

You can modify that script to add on to the .htaccess to deny the attacking IP….. ie:

PHP

Open the file for appendage, write “deny from xxx.xxx.xxx.xxx”, add a new line, close/save file.

02There is a a better way to block proxy servers, using .htaccess