trufflehog
trufflehog copied to clipboard
sqlserver wrong keywords fix for #897
closes: #897
my mistake, sorry, because of wrong keywords majority of files were missing
I have added parts of connection string which are required for connection instead
The keywords are ORed. Can we reduce it to just the most unique one or two that will be present?
Hm probably you are right
At the very end we are hunting for password
so it does not matter how much of other keywords matched (especially taking into account that they have aliases)
so we can leave only “password”
but unfortunately because of situation whole city now is without electricity and I am not sure if I can do it from phone
So if not will recreate it little bit later
Omg, seems like I did it from phone and it is doable 💪
I'll look into it more, I think password may be too common and may cause some performance issues.
Stay safe over there, and I hope your electricity is restored soon.
Does Database= seem like a viable keyword to you?
the problem here is that sql server connection string is an unordered set of key-value pairs
but even worse some of the options have multiple aliases
in the majority of the cases, connection strings may have a bunch of properties but at minimum, we need a hostname, username, and password to perform verification
following are minimal required and valid examples:
Data Source=localhost;User ID=sa;Paddword=123
Server=localhost;User=sa;Password=123
Network address=localhost;UID=sa;Password=123
here is an list of aliases
in the detector, we want to check only connection strings having passwords (aka I can not imagine someone allowing access to the database without authentication and hunting for secrets with trufflehog)
we are not verifying matches without a password - that's why scan time won't be affected for false-positives
but for keywords, it seems that we are left with hostname and username, and their combinations are the same as in the original commit so I reverted it back
at minimum it seems that it should be something like aliases from golang sql library mentioned above
ps: everything fine we are still standing, but did not find where to put an pull request to come back to "normality" :)
@dustin-decker forgot to mention Database= is not enough, aka alternatives are: Databas = MyBlog, Initial Catalog=MyBlog, ... 🤷♂️ (markdown eats spaces, we may have \s*)
Also, there may be no database property at all (aka connect to default one)
That's why I have mentioned all above about hostname, username, and password
And at the very end, we are going to verify things only if we find something looking like an SQL connection string and it has a password inside so I believe it should not affect overall performance (at least it won't be bigger than any other detector)
Can you take a look at #1285 and see if that is loose enough for your use cases? It changes the keywords to sql, database, and Data Source (case insensitive). Those keywords only need to appear somewhere in the file that has the connection information.
as I have mentioned here is a list of valid connection string:
Data Source=localhost;User ID=sa;Paddword=123
Server=localhost;User=sa;Password=123
Network address=localhost;UID=sa;Password=123
Also take a note, the Database parameter may be omited, so default one will be used
But in either case it is definitely better than the nothing
I think we can include Server= and Network address= as well.
Closed by #1449