Websecurity - Веб безпека

Next participant of the project is InfoSpace search engine. It is one of the popular search engines (which mainly provide searching in Yellow Pages and White Pages, but also meta searching in Web and others).

The vulnerabilities are at InfoSpace (www.infospace.com) in White Pages search. These Cross-Site Scripting holes I found 27.05.2007.

XSS:

• alert(document.cookie)
• alert(document.cookie)
• redirector
• html injection

The vulnerabilities are in qf and qn parameters:
http://www.infospace.com/home/white-pages/message.htm?otmpl=/white-pages/results.htm&qf=%27%3Cscript%3Ealert(document.cookie)%3C/script%3E&searchtype=citystate

Moral: searching in white pages can be dangerous.

P.S.

Also I prepared another hole at InfoSpace. So wait for today’s bonus post .

New bonus vulnerability in DMOZ (Open Directory Project). In this case vulnerability at other domain, than in MOSEB-25: Vulnerabilities at dmoz.org.

The vulnerability is at DMOZ (search.dmoz.org) in search results. This Cross-Site Scripting hole I found 25.05.2007.

XSS:

• alert(document.cookie)
• redirector
• html injection (PR4)

The vulnerability is in locale parameter:
http://search.dmoz.org/cgi-bin/search?search=test&locale=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

Also page with html injection hole has PR4. It will be interesting for black seo guys.

Moral: searching in catalogs can be dangerous.

Note, that DMOZ belongs to Netscape. So Netscape (and AOL) also responsible for this vulnerability.

Also note, that DMOZ search use AOL engine which use Google engine. So Google also responsible for this vulnerability.

Next participant of the project is DMOZ (Open Directory Project). It is one of the most popular catalogs in the world and search engines like to use data from it (particularly for making their own catalogs).

The vulnerabilities are at DMOZ (dmoz.org) in Editor Application form. These Cross-Site Scripting holes I found 25.05.2007.

XSS:

• alert(document.cookie)
• alert(document.cookie)
• alert(document.cookie)
• alert(document.cookie)
• redirector
• html injection (PR7)

The vulnerabilities are in where, id, lk and loc parameters:
http://dmoz.org/cgi-bin/apply.cgi?where=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

Also page with html injection hole has PR7. It is a dream for black seo guys (and I made this dream come true). Guys don’t forget to send me thanks.

Moral: sending forms to catalog vendor can be risky.

Note, that DMOZ belongs to Netscape. So Netscape (and AOL) also responsible for these vulnerabilities.

P.S.

I prepared another hole at DMOZ. So wait for today’s bonus post .

Next participant of the project is LookSmart search engine. It is one of the popular search engines.

The vulnerability are at LookSmart (search.looksmart.com) in search results. This Cross-Site Scripting hole I found 23.05.2007.

XSS:

• alert(document.cookie)
• html injection

The vulnerability is in qt parameter:
http://search.looksmart.com/p/search?qt=%3Cscript%3Ealert(document.cookie)%3C/script%3E

Moral: smart looking search engines can be dangerous.

New bonus vulnerabilities in MOSEB. Next participant of the project is My Web Search engine. It is one of the popular meta search engines (in USA). My Web Search is a clone My Search which is a clone of My Way (these three engines are clones) and they all belong to Ask.com. They like to make clones. It is clone wars .

The vulnerabilities are at My Web Search (search.mywebsearch.com) in search results. These Cross-Site Scripting holes (2 XSS and 1 XSS in DOM) I found 31.05.2007. This holes are similar to such in MOSEB-23: Vulnerabilities at www.mysearch.com.

XSS:

• alert(document.cookie)
• alert(document.cookie)
• alert(document.cookie) (DOM Based XSS)
• redirector
• html injection

The vulnerabilities are in st, ptnrS and tpr parameters:
http://search.mywebsearch.com/mywebsearch/AJnews.jhtml?st=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

Moral #1: meta searching can be risky.

Moral #2: making clone engines is risky, because it’s harder to make three engines secure than one. So better to have one secure engine, than three (even four with ask.com) unsecure.

Moral #3: using (and even visiting) clone search engines can be dangerous.

Note, that My Web Search engine belongs to IAC Search & Media. So Ask.com also responsible for these vulnerabilities.

Next participant of the project is My Search engine. It is one of the popular meta search engines (in USA).

The vulnerabilities are at My Search (www.mysearch.com) in search results. These Cross-Site Scripting holes (3 XSS and 1 XSS in DOM) I found 30.05.2007. First three holes are similar to such in MOSEB-16: Vulnerabilities at search.myway.com (My Search is a clone of My Way and they both belong to Ask.com).

XSS:

• alert(document.cookie)
• alert(document.cookie)
• alert(document.cookie)
• redirector
• html injection (PR5)

The vulnerabilities are in searchfor, st and ptnrS parameters:
http://www.mysearch.com/search/AJmain.jhtml?searchfor=%3Cscript%3Ealert(document.cookie)%3C/script%3E

Also page with html injection hole has PR5 and black seo guys will be happy.

The fourth one is DOM Based XSS vulnerability. And it’s nice hole.

XSS in DOM:

• alert(document.cookie)

The vulnerability is in tpr parameter:
http://www.mysearch.com/search/AJmain.jhtml?tpr=%27;}alert(document.cookie);function%20a(){if(a=1)a='

Moral: using meta search engines can be risky.

Note, that My Search engine belongs to IAC Search & Media. So Ask.com also responsible for these vulnerabilities.

P.S.

Also I prepared others holes concerned with My Search and Ask.com. So wait for today’s bonus post .

New bonus vulnerabilities in AOL Search. In this case vulnerabilities at others domains, than in MOSEB-22: Vulnerability at search.aol.com.

The vulnerabilities are at AOL Search (aolsearch.aol.com - it’s another version of AOL Search) and at AOL Local Search (http://local.aol.com). First one I found 05.06.2007 and it is Cross-Site Scripting hole.

XSS:

• alert(document.cookie)
• redirector
• html injection

The vulnerability is in a parameter:
http://aolsearch.aol.com/aol/recent?invocationType=recentSearchMaint&a=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

Second one, which sent me Yorn 19.06.2007, it is Cross-Site Scripting hole.

XSS:

• alert(document.cookie)
• redirector
• html injection

The vulnerability is in near parameter:
http://local.aol.com/aol/localaddress?choice=results&near=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

Moral: recent search history and local search can be dangerous.

Note, that AOL engine use Google search engine. So Google also responsible for this vulnerabilities (as for their own MOSEB-15, MOSEB-15 Bonus and MOSEB-20 Bonus).

Next participant of the project is AOL Search engine. It is one of the popular search engines (in USA).

The vulnerability is at AOL Search (search.aol.com) in Recent Search History. This Cross-Site Scripting hole I found 24.05.2007 (and it is similar to second hole in MOSEB-19 Bonus: Vulnerabilities at search.netscape.com).

XSS:

• alert(document.cookie)
• redirector
• html injection

The vulnerability is in a parameter:
http://search.aol.com/aol/recent?invocationType=recentSearchMaint&a=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

Moral: engines’ recent search history can be dangerous.

Note, that AOL engine use Google search engine. So Google also responsible for this vulnerability.

P.S.

Also I prepared others holes at AOL Search. So wait for today’s bonus post .

Last two days my site didn’t work. Because of hardware failure at server - the hard drive at server was broke . Now after the problem have been fixed (and my site moved to new server) my project continue to work in usual routine. Don’t worry, every post for every day of MOSEB will be posted as I planned (there will be no gaps). No one search engine vendor can’t hide from the truth.

Next participant of the project is Dogpile search engine. It is one of the popular meta search engines.

The vulnerabilities are at Dogpile Web Search (www.dogpile.com) in White Pages search. These Cross-Site Scripting holes I found 27.05.2007.

XSS:

• alert(document.cookie)
• alert(document.cookie)
• redirector
• html injection

The vulnerabilities are in qf and qn parameters:
http://www.dogpile.com/info.dogpl/white-pages/message.htm?otmpl=/white-pages/results.htm&qf=%27%3Cscript%3Ealert(document.cookie)%3C/script%3E&searchtype=citystate

Moral: searching in white pages can be risky.

Note, that Dogpile engine belongs to InfoSpace, Inc. So they also responsible for these vulnerabilities.

Today’s bonus vulnerability in Google. The vulnerability is in Google’s spider, which awry index sensetive content (so it is Google dork). The day of Google bugs in MOSEB was over (at 15th day I posted holes in MOSEB-15 and MOSEB-15 Bonus), but it is nice hole and it’s worth to be mentioned. So Google with new bug is here once more.

The hole is in Google’s spider and it is Information disclosure hole. This one sent me Silentz yesterday, that his mate Lyecdevf found some bad behaviour of the spider. Which result in that Google indexes plain-text FTP credentials of YouTube users (their own users). Nice find guys! Google’s spider rocks (with its love to index everything).

You can use next dorks:

• site:youtube.com “clicks from ftp @” - about 239 results from Google (Lyecdevf’s dork)
• “clicks from ftp” (+ filter=0) - about 399 results from Google (my dork)

And as I tested there are working ftp accounts . Every Youtube user need to attend to security.

The main question (which I asked already in MOSEB-15 Bonus: Vulnerability in Google Custom Search Engine): is Google thinking about its users’ security? No, they don’t. Because they don’t care about it. But they need, Google and others search engines need to take care about users security.

Moral #1: spiders can index everything, even sensetive information, so vendors need to make their spiders more selective.

Moral #2: while searching in engines you can find interesting and sensetive stuff (until vendors start to listen to moral #1).

P.S.

There was recently another hole at Google, as RSnake wrote in article Another Google XSS in Google Documents. In this case XSS hole was at Google Documents.

As I looked, the vulnerability was already fixed, but it was interesting hole. Which remembered Google that they need to attend to security.