Hi Everybody,
I step in here, with my two euro cents worth.
I see a basic design flaw happening here.
That is you do not to be doing consistency checks.
It is possible to find out if something goes wrong during the arching process.
Check the API for NSKeyedArchiver.
Maybe, I am to old school, but I have learned working with any similar
to a database you need consistency checks before you commit.
The same goes for any input to a program. Either, control the input to your
system,
or make sure it does not cause problems.
regards
Keith.
Am 22.02.2013 um 07:37 schrieb Alex Zavatone <z...@mac.com>:
>
> On Feb 22, 2013, at 1:15 AM, Jens Alfke wrote:
>
>>
>> On Feb 21, 2013, at 8:34 PM, Gerriet M. Denkmann <gerr...@mdenkmann.de>
>> wrote:
>>
>>> Well, the opposite of: "can store all strings" is: "can store only certain
>>> strings".
>>> My point is that the number of unstorable strings is greater than zero.
>>> Whether it is 1 or any other number is quite beside the point.
>>
>> Yes. What makes this so bad is that it’s pretty likely that some strings
>> stored in an archive are created outside the program’s control, i.e. by a
>> user (or worse, possibly from data received over a network.) That means you
>> have to explicitly guard against un-archivable strings, maybe by escaping
>> them somehow, or run the risk of crashes or corruption. And we don’t even
>> know for sure what the full set of un-archivable strings is.
>>
>> It also doesn’t matter how obscure/unlikely those illegal inputs are. Let’s
>> say you wrote an IRC client that persists transcripts using an
>> NSKeyedArchiver, with a data structure where every message is an NSString.
>> Makes sense. So then all someone has to do is type the message “$null” into
>> an IRC chat, and boom! Everyone in that chat room using your client
>> simultaneously gets kicked out with a crash.* Instant DoS attack. In this
>> case it wouldn’t matter if the illegal string were a specific 800 characters
>> of gibberish; once someone found out the bug, that string would become
>> pretty widely known.
>>
>
> Exactly that.
>
> In one iOS project I have that is a front end GUI to a corporate database,
> simply entering null as a search query to the server ends up returning every
> record in the database.
>
> It's unexpected issues like this that can have really dangerous and
> unpredictable implications. Since I don't have control over the server, I
> have an array of query values to check for that could crater the server and
> filter the search input against this array to remove any of those values if
> present.
>
> Now, IF this were for a project that was, ohh, the entire sales figures for a
> large public company (it is), this is a massive security and legal issue in
> that the back end exposes the entire data set of clients (or whatever) simply
> by passing in null as a query string.
>
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
