http://qs321.pair.com?node_id=11100794


in reply to Re: How to secure SQLite3 in Windows IIS CGI
in thread How to secure SQLite3 in Windows IIS CGI

SQLite has a cheap, for-fee extension called SQLite Encryption Extension.

Without even looking at the feature: You have a webserver stupidly serving the encrypted database file. And some code (Perl script, whatever) that holds the key to the encrypted database. All that an attacker now needs is either a second misconfiguration that allows reading the perl script (or whatever binary cooperates with the webserver) to get the key, or a flaw in the SQLite encryption.

The clean way is to place the database file somewhere outside the document root of the web server. Encrypting it does not hurt, except when you have performance issues. But as long as you provide both the encrypted file and the en-/decryption key (it must be a symmetric key), all encryption is just expensive obfuscation.

Oh, and by the way: The second misconfiguration does not have to be in the web server. A simple bug in a CGI script may be sufficient. One of my favorite ones was in gzip_cnc, partly because I caused that red security warning at the top of the page. gzip_cnc runs as a CGI, and up to version 1.10, it did not validate which files it compressed and returned to the browser (see security). If you appended any URL, it bypassed all webserver security measurements and returned any file, nicely compressed with gzip. Including its own code, the code of any CGI, the contents of every file accessible to the webserver. No passwords required, all limits bypassed.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Replies are listed 'Best First'.
Re^3: How to secure SQLite3 in Windows IIS CGI
by kennethk (Abbot) on May 31, 2019 at 19:59 UTC
    I probably should have included in the post that this is but one step in a defense-in-depth strategy. If one explicitly encodes a password in a Perl program, one must assume that password is fairly visible. There are more sophisticated ways of hiding that information (e.g., password daemon) but ultimately any proof-of-identity is imperfect. Cost of hurdles must be considered relative to value of information. But simply moving the unencrypted file to a path still accessible to the web server userid leaves the DB still vulnerable.

    Thank you for describing so thoroughly the risks here. Detailed examples are very helpful in educating newer programmers, and I'm reading this as a rhetorical trick directed toward the GP.


    #11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.