Special characters in DB file name?

[toolforger]

The JDBC URL is a string which includes a file pathname.
What will happen if that name contains special characters, such as
- blanks
- colons
- semicolons
- control codes?
Reading ConnectionInfo.readSettingsFromUrl() tells me that everything except ';' is allowed.
Is that correct? Am I missing something?
Is this aspect documented somewhere?

My use case is that the file name (including directory path) is user-settable.
Since filtering is complicated to get right, I'm letting the file system decide what names are acceptable or not; however, I'm unsure about what I need to exclude from JDBC, and reading the code won't tell me what future versions of H2 might or might not accept.

[Thomas Mueller]

Hi,

On Wed, Jun 13, 2012 at 9:31 AM, toolforger <j...@durchholz.org> wrote:
> The JDBC URL is a string which includes a file pathname.
> What will happen if that name contains special characters, such as
> - blanks
> - colons
> - semicolons
> - control codes?

The same as if you try to create such a file.

> My use case is that the file name (including directory path) is
> user-settable.

Isn't this a security problem? If you want to do this, I suggest to
escape / filter / limit the name within your application.

Regards,
Thomas

[Joachim Durchholz]

Am 22.06.2012 15:12, schrieb Thomas Mueller:
> Hi,
>
> On Wed, Jun 13, 2012 at 9:31 AM, toolforger <j...@durchholz.org> wrote:
>> The JDBC URL is a string which includes a file pathname.
>> What will happen if that name contains special characters, such as
>> - blanks
>> - colons
>> - semicolons
>> - control codes?
>
> The same as if you try to create such a file.

Well, since I had no answer, I stepped through all the layers and found
this:
a) Yes, it's limited to what the file system allows.
b) However, the name is inserted into the JDBC URL, which uses ';' as a
delimiter. So even if the file system allows ';', the JDBC URL will
likely be malformed and opening the driver will fail before it gets to
file creation. (Disclaimer: The delimiter may be ':' instead of ';', but
I'm too lazy to look it up right now.)

>> My use case is that the file name (including directory path) is
>> user-settable.
>
> Isn't this a security problem?

Not for my use case, where the db is created by a local user within his
home directory :-)

[Thomas Mueller]

Hi,

>> Isn't this a security problem?
> Not for my use case, where the db is created by a local user within his home
> directory :-)

You need to make sure things like "./../../test" is not allowed. But
you also need to filter backslash, and possibly other characters,
specially escape sequences (search Google for "Double Decode File
System Traversal").

I think it's more secure to whitelist known good characters (a-z, A-Z,
_, 0-9) than to blacklist known bad ones, as you can't be completely
sure which are the bad ones.

Regards,
Thomas



>
>
> --
> You received this message because you are subscribed to the Google Groups
> "H2 Database" group.
> To post to this group, send email to h2-da...@googlegroups.com.
> To unsubscribe from this group, send email to
> h2-database...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/h2-database?hl=en.
>

[Joachim Durchholz]

Am 26.06.2012 20:56, schrieb Thomas Mueller:
> I think it's more secure to whitelist known good characters (a-z, A-Z,
> _, 0-9) than to blacklist known bad ones, as you can't be completely
> sure which are the bad ones.

It all depends.
If you don't pass the inputs to any command-line shell, you're fine.
If you make sure that every input ever passed to a command line shell
goes through a solid(!) shell-escaping library, and know what shell is
going to handle the commands, you're still fine.
You also need to know what the filesystem will accept, but if you hit a
limit there, that's not a security hole, just a failed file creation
operation (a condition that should be tested for, of course, to avoid
having bugs that might become exploits).

Of course, you want to have something like prepared statements.
And be 150% sure that the escaping library is 150% correct.
You need to plan for security.

But only if you accept remote input that might be interpreted as
filesystem paths.

>>> Isn't this a security problem?
>> Not for my use case, where the db is created by a local user within
>> his home directory :-)
>
> You need to make sure things like "./../../test" is not allowed.

Eh, nope. It's a _local_ user. These can access ./../../test anyway.

Regards,
Jo

[Thomas Mueller]

Hi,

Eh, nope. It's a _local_ user. These can access ./../../test anyway.

OK, that's fine then.

> Of course, you want to have something like prepared statements.

This doesn't work for the database URL.

Regards,

Thomas

[Joachim Durchholz]

Am 29.06.2012 11:52, schrieb Thomas Mueller:
>> Of course, you want to have something like prepared statements.
>
> This doesn't work for the database URL.

That's why I wrote "you *want*". And "something like".
No prepared statements on URLs, of course, I just meant to say that it
would be nice to have a similar mechanism to deal with escaping issues.

Not that this is possible in the case of JDBC URLs. No escaping
mechanism there (I don't know what they were smoking - probably just
time-to-market pressure, but still...)

Regards,
Jo