So this is a hard to accomplish exploit, and is really only accomplishable by first exploiting another exploit first, or by an employee with some level of trusted access, though this employee might not normally have actual database access. I do believe you should be aware of it, as it leaves open an avenue you may not be thinking of. A sample application So the first thing we need is an application that uses Flyway, let’s just use the Spring Boot Flyway Sample.

This is the story of my friends problem today. I got one for ya. Field like field so of course I’m like: “? is that a question? he had given me no prelude, no premise. response I tried field like ‘%’ + field2 + ‘%’ No good though So I explained that % is a wildcard. He still hadn’t explained what his problem is or what he was trying to do.

In PostgreSQL the ASCII NUL or empty string \0 is seen as NOT NULL. This is because postgres developers consider any characters data. I know there are better discussions on it but I can’t find them right now. Unfortunately the programming language you are using probably doesn’t see it the same way. There’s a good chance that initialized variables are set to \0 and so when you try to insert from your language to a NOT NULL field with variables that are seen as undefined in your language, postgres accepts it, and now you have fields that you probably consider to have no data but are NOT NULL.

I ran into so problems and lack of information with my last post on this topic. Firstly my syntax for local all all to local all all ident devel doesn’t seem to work in my current setup. It’s possible that it has something to do with the configuration of the Debian/Ubuntu server I was basing that against, and now my targets are Arch Linux and Slackware. So our goal here will be to provide an alternate user that can log in as postgres via ident.

If you followed my last initial setuppost on creating users and are running a default install of postgres you currently should be able to access the database on your cli. However, many distributions do not install postgres in a default manner. A great many distributions make the default authentication for sockets ident sameuser. This is technically much more secure than trustwhich is the default. However, you may find yourself locked out of your database on the local cli if you make the database name different.

So I just had a discussion on #ubuntu-server on freenode about why my not having a password to connect to postgresql via a socket (read local cli) is insecure. So I asked them, how exactly is it that someone is going to get this access? The answer “there are bad people on the Internet”. I’m sure many people right now are agreeing with them and thinking I’m crazy. Let’s discuss my setup though shall we.

This guide assumes that you’ve managed to install and start the postgres server. I’m ignoring these because they are well documented in several places, probably including your distribution, however, what to do next isn’t. First you need to connect to the Postgres database with psql as postgres, on gentoo* distributions you must be in the Postgres group to do this. In the event this doesn’t work you may have to su to the postgres unix user account somehow and run psql from there.

If you’ve ever used \edit with PostgreSQL you’ve probably noticed that it’s not using syntax highlighting that your favorite editor most likely supports. I’ve wondered why this is for a while, Postgres uses vim on my system which supports robust highlighting among other things. I had a few things suggested to me, such as setting putting settings in my .vimrc, most of which would have forced filetype=sql on files that weren’t sql, and would have been active outside of psql.