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: Fri, 21 Apr 2006 16:43:51 +0200
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.

All user data that's truly free-form should never have any impact on the program's behaviour and should thus pass through unmolested and unvalidated. This is OK so long as the author knows about it (free-form data designated for use in database queries are *not* free-form).

Most web-application security holes come from programmers attempting too much dwimmery, making not only the application slower and more cumbersome to maintain, but also significantly less secure. Userfriendliness should be mainly in error-messages, not in logic code.

/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>