[BUG] cannot connect to DB for sql injection lesson #502
Comments
|
I also tried with the latest version of security shepherd (from the git repository) rather than release 3.1. Had the same problem. |
|
Looking at your log file; there seems to be a problem with your hostname: The SQL challenges work by using grants in the following way The above SQL script has localhost. We then SecurityShepherd/docker/mysql/Dockerfile Line 10 in d5c7166 The problem looks like somehow the hostname has been changed on your environment, it should be; Line 26 in d5c7166 Not Can you confirm you haven't done anything to modify you docker network to be called The network name is set up in the docker-compose.yml SecurityShepherd/docker-compose.yml Line 12 in d5c7166 |
|
Thanks for your help! Definitely gives me something to look into, at the least. I haven't touched the default docker networking configuration at all, and my If it makes any difference, I'm connecting to this machine over the Internet. I don't recognize the IP address 172.18.0.4, I'm assuming that must be on the network created by docker-compose? Any other things I might try? I've verified the content of |
|
Maybe the 31 came from using the 3.1 release? I don't know how it would have persisted... I did a full |
|
So I've started over with the github code, and the issue with "securityshepherd31" is all gone. But now I'm still encountering the message below. It seems like the network connectivity is working, but the password is wrong? I don't see how that's possible with all the default config. |
|
After experimenting with networking settings for a while, I managed to solve the problem by changing the sql script so that it uses a wildcard hostname. Since docker-compose uses its own network that shields mysql from external hosts, I don't think this poses a risk to the security of the system. Would you be open to a pull request that updates the sed command in the docker file to do this? (I looked for other solutions but couldn't come up with anything; I tried using different versions of Ubuntu to see if the version of docker made a difference, but that didn't help.) |
Yeah that might be the case but its not clear how that is happening?
You are correct with your solution by changing the script. You can modify the sed command in the docker image to allow everything with a wildcard or remove them completely from the core schema. But it's there because of a security concern and when I built the docker images I had to work with those grants. Shepherd is still being release as a VM and we have to factor in. Before we accept a change in how the grants are I'd like to run it by @markdenihan first. |
I can answer that now: the docs say "Your app’s network is given a name based on the “project name”, which is based on the name of the directory it lives in. You can override the project name with either the --project-name flag or the COMPOSE_PROJECT_NAME environment variable." Because I unzipped the tarball from the website, the default folder name
Instead of changing the SQL script, we can change the dockerfile that mangles the SQL script. That way it only affects docker builds, where none of the database services are exposed anyway. We could look for other solutions, but I think this will be the most reliable. Looking forward to @markdenihan 's comments. |
|
That's some really nice work! Thanks. I agree with your solution if you want you could create a branch called We can review it and look to merge it into |
|
Hi I found that changing the current path to 'securityshepherd' can resolve the problem. Hope it useful for others. |
Describe the bug
After following the docker setup instructions with the latest release, some of the lessons won't work. In particular, the "Sql Injection" lesson (the first, unnumbered one) won't accept any correct answer. Instead, there's an error in the console about tomcat being unable to connect to the database with the user
firstBloodyMessL.To Reproduce
Steps to reproduce the behavior:
Expected behavior
It gives the key for the lesson.
Actual behavior
It says the answer is wrong -- even when it's right. A log message appears in the console showing that tomcat could not connect to the database with the appropriate account:
Desktop (please complete the following information):
Further Information:
mvnversion 3.6.0dockerversion 18.09.7docker-composeversion 1.17.1javaversion openjdk 11.0.4The text was updated successfully, but these errors were encountered: