Skip to main content

Posts

Showing posts from May, 2009

HTTP Parameter Pollution

At the OWASP AppSec Europe, researchers demonstrated a very interesting otherwise underestimated issue. Although not a new attack category but quite dangerous if executed flawlessly. It exploits the fact how does your application behaves when receives multiple parameters with same name in same URL. For example, .../bank.php? action=view &accID=101& action=withdraw In URL above two one parameter 'action' has multiple occurrences with same name in same URL. What will the web application do? It can do one of the following depending on the environment it is using: It may only take the data from the first parameter It may take the data from the last parameter It may take the data from all parameters and concatenate them together Now we know that for the specific above URL the second action is quite dangerous! Using this technique even WAF (Web Application Firewall) can be evaded, it won't filter the request. Suppose a WAF is designed to detect and filter out attacks

Just an eyewash ?

Rediff gave an eyewash? Too early to comment. The main page search engine is not executing normal scripts now but not able to thwart encoded ones. I think they are now rectifying the problem step by step. Apart from this every second search module is suffering like Product search, Shopping, Matcmaker, Astrology, Jobs endless. Wherever is search module..high chance of vulnerability. They should visit XSSed.com for more information about the vulnerability on their site. Wait is longer... they might have just started the process of rectifying the problem. Let's wait for few days more.

CSRF attack manipulates Times Poll

Again Time magazine has become a victim to CSRF attack. A person called Moot got the most votes not by the normal public bu by manipulating the poll process by Moot's supporters. The supporters of Moot analysed the link that actually submit the user's vote to the application: http://www.timepolls.com/contentpolls/Vote.do?pollName=time100_2009&id=1883924&rating=1 Then they created an auto Voter URL:http://fun.qinip.com/gen.php?id=1883924&rating=1&amount=1 The arguments the specified the ID of the person to be voted,the rating to be given to the person and how many times they are being voted. With this information, the attackers could abuse the amount argument to vote more than one time: http://fun.qinip.com/gen.php?id=1883924&rating=1&amount=200 Each time this URL was accessed, it was equivalent to 200 individual normal requests. Time actually identified the manipulation and came with antiCSRF tokens that were MD5 hash of URL + salt va

IE is really unsafe?

Is IE unsafe? I tend to conclude so, regarding my interactions with Giorgio on an issue of XSS in Paypal. This is because the flaw in IE that it doesn't encode the URL before sending it on the wire. While interacting with Giorgio I came across something new to me: InputDecoding. As Giorgio says: @ Nilesh : In the Paypal case, it’s not doing output encoding, it’s skipping input decoding (quite strangely). The correct workflow should be: Input decoding (decodeURIComponent) Input validation Output with output-specific (HTML or JavaScript) encoding This Paypal page was missing all the 3, and only by luck the fact browsers different by IE properly encode the URL saves them from XSS. The InputDecoding as far as I can understand is the process of getting back the URLencoded input in original form so that application can understand it properly and exeute it. After executing the application once again must escpae the output in proper manner (HTML escape or Javascript escape). Again,

WASC Web Vulnerabilities classification schema

I came across another effort to systematically organize web application vulnerabilities, include six categories published by the Web Application Security Consortium (www.webappsec.org). They are very clearly and neatly organized.The following descriptions of web vulnerabilities are modeled on the WASC schema. Authentication – stealing user account identities -> Brute Force attack -> Insufficient Authentication -> Weak Password Recovery Validation Authorization – illegal access to applications -> Credential / Session Prediction -> Insufficient Authorization -> Insufficient Session Expiration -> Session Fixation attacks Client-side Attacks – illegal execution of foreign code -> Content Spoofing -> Cross-site Scripting Command Execution – hijacks control of web application -> Buffer Overflow attacks -> Format String Attack -> LDAP Injection attacks -> OS Commanding -> SQL Injection -> SSI Injection -> XPath Injection Information Disclosu

New Search Engine from Microsoft- Kumo!

A new Web Search Engine from Microsoft " Kumo "--a Japanese word for 'cloud' or 'spider'. It is being said that to compete with others search engines major like Google and Yahoo, Microsoft has actually developed it. However it's not available publicly on net but earlier this month Kumo was released for internal testing for MS employees. Several screenshots have also surfaced over the Internet . It looks refreshing ! More info at : http://blog.seattlepi.com/microsoft/archives/163312.asp

It pays to be patient, Rediff awakes!

A surprising series of events: *Couple of months back I reported XSS and SQL Injection to Rediff . It was painstaking effort as I had to search for the person concerned for security incidents. I connected to him, he happily requested and accepted my advisory. * No Update from them..the vulnerability still existent. *No Update from them..the vulnerability still existent. *................. *No Update from them..the vulnerability still existent. * Meanwhile I left the hope of feedback and saw somewhere on the net that there have been already reported XSS about their site. It proved their laxity and negligence. I ignored the issue. * This month somebody discovered XSS again on Rediff ( like I had, few months ago). * He posted it on Owasp Delhi Mailing List. I responded to the post and told them about my reporting. * Nitin Saxena ( Owasp Delhi Chapter Lead), urged me to send him the all the communications by me to Rediff and advisory as well. He was

Yes IE also susceptible

I got my queries satisfied from Giorgio about my previous post : Nilesh says: May 13th, 2009 at 7:38 am Hi Giorgio, When I cleared the history of Mozilla FF, visiting on startpanic.com didn’t yield any result. The bug lifts information about visited website from the history. Isn’t it? Is IE also susceptible? My IE 7.0 gets hanged whenever I visit startpnaic.com and click Check. Why? Giorgio says: May 13th, 2009 at 7:21 pm @ Nilesh : >>The bug lifts information about visited website from the history. Isn’t it? Yes. More precisely, attackers can tell if a certain URL is present in your history or not (they’re using a list of 100,000 to be impressive). >>Is IE also susceptible? Of course it is. Every modern browser susceptible. >>My IE 7.0 gets hanged whenever I visit startpnaic.com and click Check. Why? Because its JavaScript interpreter sucks?

Some one watching where you visited!

Yes... Mozilla has been susceptible to browser-history stealing java script code. Today, Giorgio posted some cool information about the exploit. Mozilla is already working on this. This bug has been reported. Actually they have set up a web site to show the proof-of-concept. Visit www.statrpanic.com in FF,Safari or Netscape and it will tell you which websites have you been already ! But I am not sure it will work in IE or not because my IE is not responding to the website. Clearing history of visited website makes you safe to this attack. I mean this is one way..may be there are other ways to exploit this. But I have found this effective. Try it yourself in FF and then in IE and see the results.

Naughty ' or ''=' still works! ;)

Yes nothing new about this...I agree. This is one of the primary tools used by pen testers for detecting SQL injection flaws. So it's quite natural for any developer to have knowledge how to thwart this kind of attack from happening in their application, I mean ,very basic thing a developer can do in their application,the first line of defence against SQL injection attacks it is. And they do, I have hardly come around this sort of negligence in any application I have audited. But can you believe that one of the major website of an Airline is susceptible to this(sorry...I can't disclose)?? Even the site is very much live, used by customers, for doing transactions. I was taken aback by this incident. Just supplied the query and voila! I had broken their authentication and clearly seeing the account of first customer. That's not single case..this happened at two different login sections ,one for customer account and another for Agent account. Really surprising, this can