Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

Re: Canonicalization

Subject: Re: Canonicalization
Date: Mon, 24 Apr 2006 11:08:29 +0200
Jason Murray wrote:


exon wrote:

Peter Conrad wrote:

Hi,

On Thu, Apr 20, 2006 at 10:22:18PM -0400, Rossen Raykov wrote:

Is that ?simplest form? achievable? One can perform many and different encodings making the task of decoding them very difficult and resource consuming. Usually it is cheaper and safeties to do semantic checkup and treat the input as erroneous if it does not confirm to the expected input format.




you're comparing apples with oranges here. You must perform canonicalization
*before* you can match the input against the expected format.



For example if you are expecting number anything different than a number is error.




Here are some different representations of the same number:

11
+11
11.0
11.00
011



This is just stupid. If the user is supposed to input an unsigned numeric integer it's just dumb to accept dots, plusses, commas and any other char than what fits in 0-9. Leading zeros can be stripped, although if the application itself never adds them you shouldn't allow that either. Even if you accept negative numbers or floating point numbers there's still a very limited range of characters to accept.


Alright then with 11.00 you strip the "." and are left with 1100. But that is clearly not what the user intended. They intended 11. You need to canonicalize to a normalized form before you can then reject for innapproptiate values.


Disallow, not strip. Stripping unallowed chars before validating is exactly the kind of dwimmery that cause bugs with input that *looks* valid but really isn't.


/exon

-------------------------------------------------------------------------
This List Sponsored by: SPI Dynamics

ALERT: "How A Hacker Launches A Web Application Attack!" Step-by-Step - SPI Dynamics White Paper
Learn how to defend against Web Application Attacks with real-world examples of recent hacking methods such as: SQL Injection, Cross Site Scripting and Parameter Manipulation


https://download.spidynamics.com/1/ad/web.asp?Campaign_ID=701300000003gRl
--------------------------------------------------------------------------

<Prev in Thread] Current Thread [Next in Thread>