RSnake

Good old server-status, which is switched on an open to all in the default httpd.conf in Apache.

Taken alone this isn't much to worry about - it is unwanted information spillage. But it gives away enough information that could be useful as part of another attack.

Since it logs URLs being hit, it can show private URLs - such as those that depend on randomly generated tokens to access data (eg. photobucket photos) or to determine the structure of a backend admin app.

It can also expose sessions in apps that use tokens in URL query parameters where cookies are not allowed (ironically something that older versions of PHP did by default).

It is also useful in measuring the progress of a DoS attack, especially with slorloris[1].

All of the standard web security scanners check for this page, and rate the severity of the information leak as moderate. What is surprising here is that it hasn't been discovered earlier, considering how often large sites such as php.net would be scanned by such scanners.

That would suggest that this is a temporary configuration glitch, or something that they don't mind being publicly accessible due to the type of content hosted on php.net and the fact that it is mirrored by volunteers anyway.

It would be much more interesting if this happen to, say, Twitter. It did, and I wrote about it at the time (I got a bit carried away, cringe:

http://techcrunch.com/2009/10/21/twitter-you-say-transperancy-i-say-vulnerability/

They closed it up quickly.

To…

Some potential mitigating factors, if you break it up as follows:

* a tiny anchor HTML page with data key info

* a general purpose .js file (or small number of such)

* template HTML pages

* content (e.g. - JSON)

The tiny "anchor" page should be small (latency still hurts, of course);

The JS should be cached locally once the app has been used for the day;

The HTML templates pages should also cache;

The content must be loaded, suffering latency -- however, if the content is large, your app can display something while the content is being generated (perhaps by a big, slow, legacy data source???).

Another consideration: if all content is delivered via a REST API as JSON or (ugh) XML, there is a better chance it will be properly encoded for display. Hopefully, I can save a nice JavaScript fragment in a submission to said site, and the AJAX page construction code will simply add it to the resulting page to be displayed, rather than to be run. Hmmmm, perhaps I want my testing fixtures to fill the test database with XSS samples while I am at it, such as the newer entries in http://ha.ckers.org/xss.html (or a more recent list), and then to display that data on a few pages of manual testing.

So even if Scala is ahead in this (flawed) benchmark, that's not how you write a TCP server in Scala, because you want to do it non-blocking. Not doing it based on asynchronous I/O means that in a real-world scenario the server will choke under the weight of slow connections, not to mention be susceptible to really cheap DoS attacks like Slowloris [1].

Seriously, it goes beyond the underlying I/O API that you're using. If anywhere in the code you're reading from an InputStream or you're writing to an OutputStream that's connected to an open socket, then that's a blocking call that can crush your server. Right now, every Java Servlets container that's not compatible with the latest Servlets API 3.1 can be brought down with Slowloris, even if under the hood they are using NIO.

Option A for writing a server in Scala is Netty [2].

Option B for writing a server in Scala is the new I/O layer in Akka [3].

[1] http://ha.ckers.org/slowloris/

[2] http://netty.io/

[3] http://doc.akka.io/docs/akka/snapshot/scala/io.html

Just a public service announcement-- for those of you looking to validate your own site for XSS exploits, you'll find that this list is particularly good at giving you "problem" strings to test against:

http://ha.ckers.org/xss.html

We honestly thought we secured XSS with common libraries on every field for one of our sites, but we paid a contractor to go through and use those strings in various unexpected places and they found a few special and unobvious spots that fell between the cracks.

Don't think you're immune just because you use all the right frameworks and input sanitation tricks. Even the best web developers are going to mishandle things from time to time.

If you think it's irresponsible for Twitter to miss some XSS vulnerabilities, you better be doing this testing on your sites, too, before someone else does and calls you out on it. If you're not testing at least the easy user input exploits, you don't really know how protected you are.

The Top-10 is just a start. As a penetration tester and sometimes-trainer, I find it's when developers start to see practical demonstrations of what these vulnerabilities can actually allow a malicious party to achieve that the eyes really get opened. Particularly when those demonstrations are within their own applications.

Check out the rest of the OWASP site, and play with WebGoat (http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project).

Take a look at the 'Web Security' section here: http://code.google.com/edu/courses.html

Start following some of the many webappsec blogs floating around the interwebs, subscribe to mailing lists, read tweets:
http://www.gnucitizen.org/
http://ha.ckers.org/
http://jeremiahgrossman.blogspot.com/
http://www.webappsec.org/lists/websecurity/
http://twitter.com/#search?q=%23WebAppSec

There is a huge amount of information out there.

I wouldn't trust this service, because I can't find any information about who is running this service - at least not in the few minutes I have spend clicking around on their site. Maybe there is some info somewhere, I have not found it.

In another comment a quote from a different article was mentioned regarding the Terms of Service. I could not find a page about the terms of service. Maybe it's me, but I think that these informations should be easy to find on a site.

Some other interesting points about this service are explored in an article by rsnake from ha.ckers.org:

http://ha.ckers.org/blog/20100104/anonymous-proxy-woes/

"So yeah, please don’t use CGI proxies, unless you really know what you’re doing. They really very rarely increase your security. Most of the time, they just decrease it, as a matter of fact."