On 12 April 2011 01:41, Ken Wesson <kwess...@gmail.com> wrote:
> On Mon, Apr 11, 2011 at 7:09 PM, James Reeves <jree...@weavejester.com> wrote:
>> You wouldn't necessarily need to explicitly verify each precondition,
>> but it might be the case that the same string is parsed multiple
>> times. However, I'm unsure why you think this is a problem.
>
> I don't. My own code posted earlier parses some strings multiple
> times.
Okay. But in which case, why do you then say:
> Either you end up with duplicated code for every
> separate integer range check (bad)
Why is this bad? I thought we just agreed that there's no particular
problem in parsing the same thing multiple times?
>> But it's compound by necessity, and has a
>> singular purpose - to validate a particular object.
>
> So's mine.
Not really. For instance, take this function:
(defn validate-user [user]
"Validates parameters describing a user."
(validate user
[:email present? "must be present"]
[:email email-address? "must be a valid email address"]
[:password present? "must be present"]))
Although this is a complex function, we can describe everything a
developer needs to know about this function in one sentence. You don't
need to know what validations are in this function in order to use it,
and as long as you know the type of map the `validate` function
returns, you need no more information.
But your not-int-in-range? cannot be described in such simple terms,
because any developer using it would need to know which keywords it
returns, and under what circumstances it returns them. A doc-string
for your function would necessarily be much longer:
(defn not-int-in-range? [x min max]
"Determines if an string, x, representing an integer fall between
the numbers min and max. If x is blank, :blank is returned; if
x does not contain an integer, :non-integer is returned; if x is
too low, :low is returned; if x is too high, :high is returned; if
x represents an integer that falls between the range min to max,
then false is returned."
...)
The simplicity of a function is more a question of what it does, than
how it does it.
>>> If you forget to do *anything* in a security-critical system, that's a
>>> potential security risk.
>>
>> If you forget a "deny" rule, that's a potential security risk, but if
>> you forget an "allow" rule, it usually isn't.
>
> But it sometimes is.
I didn't say otherwise. You were claiming that forgetting *anything*
would cause a security risk; I was pointing out this wasn't true.
>>>> If, on the other hand, you forget to validate a field that is deny by
>>>> default, then you end up with a failed validation.
>>>
>>> Depending on the application, even dead functionality can be a
>>> security risk. Perhaps it causes a police fingerprint-database search
>>> to not work or produce a false negative, for instance.
>>
>> But these situations are rare, and usually easily discovered.
>
> But, but, but. You made a universal statement that I've proven was
> wrong. You've basically admitted this by admitting that there are any
> exceptions at all to your "universal" rule. So, why keep arguing?
What universal statement are you talking about? All I said was:
"If you forget to validate a field that is deny by default, you end up
with a failed validation"
How exactly have you proven that wrong?
>> it helps to have sensible defaults, and "deny all" is usually the most
>> secure place to start.
>
> Again, that depends on the system and on what you mean by "secure". Is
> "deny all" a sensible default when designing MP3 player firmware?
> "Security" in such a context means "nobody unauthorized can screw with
> my music storage, organization, and playback". Things not working
> would be the player's manufacturer having effectively screwed with
> your music storage, organization, and playback.
That's the strangest definition of "unauthorized access" I've ever heard.
The authorised user is the one who owns the device. Whilst it's being
manufactured, the manufacturer owns the device, so you can't describe
anything the manufacturer does during that period as being
unauthorized.
If the manufacturer created the MP3 player, sold it to you, and *then*
remotely bricked it, you'd have a case of unauthorized access. But if
the manufacturer bricks the player *before* you become the authorized
user, then it's not unauthorized access.
> There is no single right answer here that is
> independent of the application's basic nature and use context!
There may be a case where an erroneous validation error results in a
security flaw, but I can't think of one, and I've never come across
one in practise. However, I've come across many, many security flaws
caused by missing validations.
In my experience, "deny-by-default" is the right answer in at least
99% of cases.
- James
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
