Slashdot Mirror

Google used to have a problem with malware and phishing sites being hosted on their own Google Sites. Once they plugged that hole, the malware moved to Google Spreadsheets. Because you can put HTML in Google's spreadsheets, it can be used as a free hosting service. Google hadn't anticipated this, and their abuse operation couldn't handle it.

Google seems to have plugged the spreadsheet hole now. I noticed recently that Google has disappeared from our major domains being exploited by active phishing scams. There were pages hosted by Google which were in Google's own "this site may harm your computer" blacklist. So their hostile-site detection wasn't coupled to their abuse department. That was kind of embarrassing, but until we publicized it, it didn't get fixed.

Basic truth - run a free hosting service, a free "forms" service, a free "poll" service, or a free URL direction service, and you will end up hosting phishing sites and related annoyances. If you run a free service, you must have an automatic check against the major phishing blacklists, or you will be pwned. This week's big sites being abused by phishers are "piczo.com" (social networking for teenage girls), "webs.com" and "moonfruit.com" (free hosting), and "t35.com" (which, the last time we contacted them, has one poor abuse guy trying to deal with a daily tide of phishing pages by hand).

Those sites are used by the bottom-feeders of the malware/phishing world. The big guys buy hosting with stolen credit card numbers, use botnets, and contract with "bullet-proof hosting services.

There is progress. "Open redirectors" are more or less gone from major sites. Over the last three years, MSN, Yahoo, eBay, and Facebook have all had open redirectors. Publicity and nagging put a stop to that. Slowly, too slowly, IE6 is dying out.

When I use NoScript to disable JS for a website, at least I have control over it.

Yeah, sure you do... Funny thing about NoScript, it allows you to run JS on sites you trust.

This is just more security theater; Consider cross site scripting attacks. I've seen XSS attacks on Google, Microsoft, Twitter, Amazon, and many more "reputable" sites that you may "trust".

NoScript security comes from not running JS. If you run any JS, you are then no longer secure. How do you know the JS you just allowed to run on a "trusted" site doesn't contain malware delivered via XSS? You Don't.

Granted, NoScript does increase your security because you're running less JS code, but it does not make you invulnerable to JS exploits unless you never allow JS to run.

The "control" you think you have can be ripped away from you by one XSS attack; So, what control do you actually have?

If you pay a qualified expert, they ought to be able to point you in the right direction. I would want to meet them physically though.

That story you mention sounds like the Jarlsberg one. The idea is you learn to secure your web application by exploiting a demonstrably weak one, so you learn your lesson. If you have the time, I definitely recommend working through it all. (story Jarlsberg homepage)

Another area to look at is simply your web server configuration. Your web application never runs in isolation. You have databases, web servers, sever side languages and other web applications that you use that are exploitable. Try to do as much checking as you scan for any obvious flaws, use tools to help you.

Run configuration file scanners for Apache, PHP*. Although I must stress I have not tried any of these, I just know they exist. I found these by just searching 'php scanner' and 'apache configuration scanner'.

Obviously they do not replace simply being careful or a whitehat's opinion and not trusting tools blindly. (A black hat probably doesn't release all his tools) Also try some generic vulnerability scanners which look for insecure installations that your web host may have installed like web mail and phpMyAdmin.

Just remember the environment.

• List of scanners
• Web application security scanners

XSS FAQ
http://www.cgisecurity.com/xss-faq.html

WASC Threat Classification - Cross-site Scripting
http://projects.webappsec.org/Cross-Site+Scripting

There are some good automated security scanners out there. For instance: Nesses/Nikto, WebScarab with proxmon, portswigger, and you can even go as far as using 3rd party companies such as HackerSafe.com or SecurityMetrics.com. Even though this doesn't give you a 100% fail-safe security scenario (*cough* nothing does and probably never will), it at least helps decrease the chances of common and even some more uncommon attacks such as SQL injections, overflows, man-in-the-middle attacks, etc. You also obviously have to write secure code and keep all of your software up to date (especially open source software). This is not only true for PHP, but for all programming languages. You should also try using BSD since you have a LAMP system. Some other good sources of information: http://www.webappsec.org/ http://www.owasp.org/ Hope this helps...

• Web Hacking Incidents Database
• Attrition.org Data Loss Archive and Database
• Internet Storm Center

The risks of interview candidates missing out on job opportunities because of MySpace profiles is a well-documented situation. I have seen real life examples of this.

My favorite example of the risks of these social networks, recently, was when I was looking into a product that was provided by a competitor of mine in the business world. By searching for one of the suppliers of the competitive product, I was able to discern many of their business contacts, which gave me a view of their customer base, their prospect list, etc. A VERY nice trove of information to get for FREE about my competition! Unless you feel you can trust the MOTIVES and the TECHNICAL CAPABILITY of these companies (LinkedIn, Facebook, etc.), don't do it! Their motives must align with yours (your privacy over their profit) and their technical capability (and investment in your privacy) must be great enough to protect the security of the information. Given that a measured 67% of sites are vulnerable to XSS hacking, and every site is susceptible to SOME malicious hacking (by employees, for example), I think it's a safe assumption that your private information is not 100% safe with some random Social Network site.

Hence the reason to disable remote 3rd party images in your browser of choice (e.g. Firefox) and never click on 3rd party URLs. See also the Netflix CSRF vulnerability that allowed an attacker to add a movie to a user's queue, move it to the top of the list, and change the shipping address for the user to his own to get free movies. Who here checks the box to stay logged into Netflix? Note that the "add movie to queue" portion still hasn't been fixed.

There may be a lot of comments saying CSRF is so 20006. Well, yes, that is true, but Grossman is probably right in that this year will be a big year for reporting the vulnerabilities (also known as session riding), because almost no Web site has any CSRF protections.

By The Web Application Security Consortium "From a counter-intelligence perspective, standard honeypot/honeynet technologies have not bared much fruit in the way of web attack data. Web-based honeypots have not been as successful as OS level or other honeypot applications (such as SMTP) due to the lack of their perceived value. Deploying an attractive honeypot web site is a complicated, time-consuming task. Other than a Script Kiddie probing for an easy defacement or an indiscriminant worm, you just won't get much traffic. So the question is - How can we increase our traffic, and thus, our chances of obtaining valuable web attack reconnaissance? This project will use one of the web attacker's most trusted tools against him - the Open Proxy server. Instead of being the target of the attacks, we opt to be used as a conduit of the attack data in order to gather our intelligence. By deploying multiple, specially configured open proxy server (or proxypot), we aim to take a birds-eye look at the types of malicious traffic that traverse these systems. The honeypot systems will conduct real-time analysis on the HTTP traffic to categorize the requests into threat classifications outlined by the Web Security Threat Classification and report all logging data to a centralized location." http://www.webappsec.org/projects/honeypots/

http://www.webappsec.org/projects/

This project is already gathering data and will be publishing the results shortly.

http://portal.spidynamics.com/blogs/spilabs/archiv e/2006/12/19/IE7-_2D00_-Phishing-vs.-Privacy.aspx

http://www.webappsec.org/lists/websecurity/archive /2006-12/msg00100.html

You are wrong, and a moron.

http://www.webappsec.org/lists/websecurity/archive /2006-07/msg00069.html

That's a cluestick pwning you.

In order to detect these sorts of vulnerabilities in an automated fashion, there are only two decent approaches to choose from:

1. Dynamic analysis: Feed the entire site, page by page, to a live browser and try to reproduce the XSS using a large number of browser actions as input. This is practically difficult and could also be quite risky (you can get owned yourself while doing it), and to get a good test you need to run a large number of inputs on several different browsers.
2. Static analysis: Spider the site and run static analysis on the JavaScript on a page-by-page basis. This is much more promising, although obviously static analysis on a language like JavaScript, which is loosey-goosey with typing, is not trivial. Shameless plug: There are only a couple of tools which can do this: NeXpose from Rapid7 is one of them that I have worked on.

var result = eval(document.responseText)

which is a bit scary when you think that it may be possible to trick the server into emitting JavaScript (which, given the limited kinds of filterings that servers do, could be easier than tricking the server into emitting HTML).

Security is a must for Web developers. There is a set of typical mistakes that are frequently made in Web applications, and most of them are not fixed automagically by using Java. Fortunately plenty of resources are available on the Net:

• The Open Web Application Security Project (OWASP) maintains a list of the Top Ten Most Critical Web Application Security Vulnerabilities and a Guide to Building Secure Web Applications. They also provide WebGoat, an application with typical vulnerabilities, for training purposes, and WebScarab, an interactive proxy for security analysis and general debugging. Both are Java applications, WebScarab running standalone and WebGoat in a Servlet container like Tomcat.
• The Web Application Security Consortium (WASC) publishes the Web Security Threat Classification, which is similar to the OWASP Top Ten, and other articles.

Make sure your developers read and understand this.

Security is a must for Web developers. There is a set of typical mistakes that are frequently made in Web applications, and most of them are not fixed automagically by using Java. Fortunately plenty of resources are available on the Net:

• The Open Web Application Security Project (OWASP) maintains a list of the Top Ten Most Critical Web Application Security Vulnerabilities and a Guide to Building Secure Web Applications. They also provide WebGoat, an application with typical vulnerabilities, for training purposes, and WebScarab, an interactive proxy for security analysis and general debugging. Both are Java applications, WebScarab running standalone and WebGoat in a Servlet container like Tomcat.
• The Web Application Security Consortium (WASC) publishes the Web Security Threat Classification, which is similar to the OWASP Top Ten, and other articles.

Make sure your developers read and understand this.

Security is a must for Web developers. There is a set of typical mistakes that are frequently made in Web applications, and most of them are not fixed automagically by using Java. Fortunately plenty of resources are available on the Net:

• The Open Web Application Security Project (OWASP) maintains a list of the Top Ten Most Critical Web Application Security Vulnerabilities and a Guide to Building Secure Web Applications. They also provide WebGoat, an application with typical vulnerabilities, for training purposes, and WebScarab, an interactive proxy for security analysis and general debugging. Both are Java applications, WebScarab running standalone and WebGoat in a Servlet container like Tomcat.
• The Web Application Security Consortium (WASC) publishes the Web Security Threat Classification, which is similar to the OWASP Top Ten, and other articles.

Make sure your developers read and understand this.

Specifically addressing the defacement incidents reported in zone-h, bear in mind that in nearly all of these incidents there is no public information on the way in which they where carried. A hacked web site does not imply that the hacking utilized an application layer vulnerability. Additionally, many defacements are not targeted and are the result of a wide scan for vulnerable sites and therefore we do not normally include defacements in WHID.

You can read more about the criteria for inclusion in WHID in the FAQ http://www.webappsec.org/projects/whid/faq.shtml

In the first case, this seems like an exploit of limited value. Great I can make you send the wrong data to a site, but what exactly would be the construction of this wrong data such that it would cause mischief. I can make you log into your bank as me... great... so you can log take all my money? I mean there may be some strange setup that this can be used to exploit but I should think it's a rarity.

You seem to miss the fact that some sites do not regenerate the session cookie upon login and reuse the session ID generated in a non authenticated area. This can lead to session fixation attacks, and, consequentely, to impersonation attacks. A malicious user could log in as a the user he "fixed" the session to.

Here's how it is done:

1. user A visits a malicious site property of user B
2. malicious user's B software generates a valid session cookie for site X (valid can be just properly formated, a valid hash or a cookie obtained from the site by accessing it without any authentication it depends on the application, really). This can be either static or dynamic
3. user A is provided a modified session cookie from site X (expiration date is set very far in the future) and the software keeps track of which user's have been given which cookies.
4. user A, later in the fure, goes to site X
5. site X does not issue a new cookie, the user's browser already provided one
6. user A logs in to site X
7. site X associates the session with the user authentication (like, say, store the session ID in a table matching session to user like many PHP scripts do or storing this in a servlet context)
8. user A uses the site
9. malicious user B goes to site X with the session cookie he provided to user A and can bypass the site authentication.

So the malicious user can impersonate the user at the site without authentication.

Of course, the problem here is with the site (steps 5 and 7), it should regenerate session identifiers, at the very least, when a user logs in. That way the authentication is associated with the new session, not the old one. However, you would be amazed to see how many sites (even banks) reuse the session identifier generated in a non-authenticated throughout a user's session, and only regenerate it when it's marked as invalid (authentication session timeout expired).

The scenario differs in the case you are handling software in which session identifiers expire even if not associated with a user session (Notice this is not typically the case for many application servers, as they don't include timestamps in sessions, typically applications will be in charge of expiring the session for authenticated users). In this scenario the malicious user B just needs to obtain the cookie from the remote server when the user A accesses his own malicious server and then redirect the user to the login of the site. This makes the attack a modified version of the traditional phishing attack, in this attack you are not asking for user's credentials since you do not need them to access the site once the user is logged in (the session ID is sufficient to access the site).

For more info check out WebApp Security threat definition for session fixation Chris Shiflett: Security Corner: Session Fixation

The Web Security Mailing List
Website Security news
Website Security news [RSS Feed]

For more information on web application attacks sign up to the web security mailing list.
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List is a good place to go if you're curious about the threats that XSS (Cross Site Scripting) and AJAX can bring.
The Web Security Mailing List

To Subscribe send an email to websecurity-subscribe@webappsec.org

http://www.webappsec.org/pr_120304.html

http://www.webappsec.org
http://www.cgisecurity.com/
What is SQL Injection?
What is Blind SQL Injection?
What is Cross Site Scripting?