WebApp Sec mailing list archives
Re: Fail Open Authentication and Parameter Injection
From: Gary Gwin <websec () cafesoft com>
Date: Thu, 27 Mar 2003 12:22:20 -0800
I think that Jeff's comments underpin the importance of reusing trusted security components across applications and externalizing security code from your application code where possible.
Frameworks like Jakarta Struts, for example, provide a nice way to leverage and implement trusted parameter checking code, and make the review process much easier by defining the control points for at least some of the form validation. Centralized application security architectures have a similar, but maybe more comprehensive goal, of removing the responsibility for authentication, access control, administration, and auditing from application code. Given the right structure, you could also automate some of your security policy authentication and access control rule testing.
Here's some recommended best practices from OpenHack 2002 that suggest some items to include in an application code security review:
http://www.eweek.com/article2/0,3959,633780,00.asp I think this list is synergistic with the OWASP Tom 10 vulnerability list. Gary Jeff Williams @ Aspect wrote:
Great example! We see bizarre stuff like this all the time. The developer may have had a reason (like only the first 8 chaacters of the password are significant or something), but the implementation came out broken. The reason is broken too, but that's a different issue. This is a perfect example of why security code review is so important. There are a million ways to mess up the implementation of a security feature, or to implement some non-security feature in a way that introduces a vulnerability. There's just no way to find all these problems by penetration testing. You might find one or two, but you'll never get anywhere close to finding them all. You just can't beat actually looking at the code. You'll need to work out a process for reviewing the code and a standard to review against. You also need to make sure you've found ALL the code. But a code review will give you some real assurance that you've covered everything...in a way that penetration testing never can. --Jeff Jeff Williams jeff.williams () aspectsecurity com Aspect Security, Inc. http://www.aspectsecurity.com ----- Original Message ----- From: Dawes, Rogan (ZA - Johannesburg) To: 'Indian Tiger' ; webappsec () securityfocus com Sent: Tuesday, March 25, 2003 2:09 AM Subject: RE: Fail Open Authentication and Parameter Injection I'll give a real world case which I found. A web app was using the following comparison for chacking passwords : and password like "$password%"; Don't ask me why they thought this was a good idea, I just know that they did it. Even providing the first character of the password would have been sufficient, but I chanced upon it when the client sent me a wrapped url with the password parameter on the next line: E.g. please start here: http://www.blah.com/mylogin.asp?username=myname &password=password When I clicked on the URL (intending to paste the rest once the browser had started up), I was logged in! Bizarre, but true! An example of parameter injection: A web app that allows you to execute a traceroute from the web server to an arbitrary destination. Takes an IP address as input, and executes something like: /bin/sh -c "traceroute $ip > file" Then reads file in, and includes it in the web page it displays to you. Provide something like: 192.168.1.1 > /dev/null ; cat /etc/shadow And with any luck, you will get the shadow file from the server instead of the traceroute output. Rogan -----Original Message----- From: Indian Tiger [mailto:indiantiger () mailandnews com] Sent: 21 February 2002 08:44 PM To: webappsec () securityfocus com Subject: Fail Open Authentication and Parameter Injection Hi, I am learning Web Application Security Penetration Testing using WebGoat. I have some queries on this. Fail Open Authentication WebGoat's step 3 says: "Try removing password parameter with Achilles. " How it's possible. Is there any chance when server don't even check password if we remove password parameter. Parameter Injection What could be the scenario where a site is vulnerable to Parameter Injections. I have given a thought on this but not able to think how exactly it works in practice. Webgoat has given an example like this 'blah & netstat -a & ipconfig' But where a developer will be allowing to insert such values. Any help on this would be highly appriciated. Thanking You. Sincerely, Indian Tiger, CISSP
-- Gary Gwin http://www.cafesoft.com ***************************************************************** * * * The Cafesoft Access Management System, Cams, is security * * software that provides single sign-on authentication and * * centralized access control for Apache, Tomcat, and custom * * resources. * * * *****************************************************************
Current thread:
- Fail Open Authentication and Parameter Injection Indian Tiger (Mar 24)
- Re: Fail Open Authentication and Parameter Injection Jeff Williams @ Aspect (Mar 24)
- <Possible follow-ups>
- RE: Fail Open Authentication and Parameter Injection Dawes, Rogan (ZA - Johannesburg) (Mar 25)
- Re: Fail Open Authentication and Parameter Injection Jeff Williams @ Aspect (Mar 25)
- Re: Fail Open Authentication and Parameter Injection Gary Gwin (Mar 27)
- Re: Fail Open Authentication and Parameter Injection Jeff Williams @ Aspect (Mar 25)
- RE: Fail Open Authentication and Parameter Injection Ramirez, Manuel N (CORP, DDEMESIS) (Mar 25)