6

I am building a web app. It is currently not open source, but I am considering making it open source, so that others can fix bugs, improve it, so that others are not suspicious of my motives (fun to code & to create a useful tool for others - not making money) and so on. It is built on PHP and MySQL.

I am also trying to follow best practices whilst creating it. So for example, logins will be protected by SSL, passwords are hashed using the bcrypt algorithm by use of PHP's password_hash function, and I use prepared statements everywhere.

However I am unsure how to proceed as I have also heard that you do not want to expose your database structure to others. I have bits of SQL all over my pages so others would have a good idea of what is stored where from looking at this code. The only thing I'm sure of is that the script with the connection username/password should not be hosted on the source repository of my choice.

How can I/should I proceed with making my code open source?

WelshGandalf
  • 63
  • 5
  • 4
    Not directly related to your question, but: `logins will be protected by SSL`. I would recommend you to protect everything by SSL, no just the login. – Anders Apr 18 '16 at 21:45
  • Is there any benefit or cost to doing so? All the other information that will be passed around is really trivial and it is not needed to keep it secure. Or is it simply good practice? – WelshGandalf Apr 18 '16 at 21:59
  • 5
    @WelshGandalf - nowadays it is considered best practice to use ssl for the entire site, for a variety of reasons: http://security.stackexchange.com/questions/258/what-are-the-pros-and-cons-of-site-wide-ssl-https. Also, Google now gives a slight boost in rankings to sites that are entirely in ssl. Plus, it's actually easier to make your entire site ssl than just part of it. – TTT Apr 18 '16 at 22:08
  • At some point you just need to put it on github.com or similiar, and start having people look at it. Google **lets encrypted** they will give you a script which will encrypted your web server. If your security is good, which you are definitely on the right track, seeing the structure doesn't automatically break things. If everything is encrypted injecting bad PHP becomes a lot harder. – cybernard Apr 18 '16 at 23:05
  • @cybernard [let's encrypt](//letsencrypt.org) that is, isn't it? The client will not encrypt the web server; it will install a certificate automatically. – Tobi Nary Apr 19 '16 at 22:53
  • @SmokeDispenser , yes that is it. – cybernard Apr 20 '16 at 02:04
  • I looked into let's encrypt but I can't use that as I'm on a shared hosting solution. I will implement https at some point though. Currently I have assigned passwords to the testers, so there is no security risk to these passwords falling into the wrong hands as the users won't be using them on other websites. – WelshGandalf Apr 20 '16 at 12:56

3 Answers3

6

This is a good question with a simple answer:

Best practices cannot be applied in every situation.

The best practices of "don't tell the world what security algorithms you use" and also "don't expose your DB structure" exist as a possible fallback- just in case your code has a security flaw in it, it's much harder for someone to exploit it if they don't know how it works behind the scenes. Obviously both of these best practices directly conflict with Open Source, so you should just focus on not having security flaws in the first place. Fortunately, opening your source code will help with that.

TTT
  • 9,122
  • 4
  • 19
  • 31
  • I like this answer the best as it is pitched at a level of knowledge that I have displayed in the question. The other answers may be useful for those with less knowledge. – WelshGandalf Apr 20 '16 at 12:57
3

Relying on keeping your schema secret to protect your system is not a good starting point. It's not Kerchoff's principle, but if the security of your system relies on the obscurity of the schema, then even if you keep it closed source and don't offer it to anyone else, you have problems.

the script with the connection username/password should not be hosted on the source repository

No.

You certainly don't want to put your database credentials in a public repository but you should put the code for managing and applying them in the report. You could use dummy values in the repo, read them from a flat file or the env, use the defaults in PHP.ini, use user-supplied credentials stored in the session, restrict access to localhost' and not require a password....there are potentially lots of solutions.

symcbean
  • 18,278
  • 39
  • 73
2

However I am unsure how to proceed as I have also heard that you do not want to expose your database structure to others.

You don't want to expose them because if SQL injection exists they know which tables to target. However, if SQL inject exists to make this happen it is a moot protection since your security is already broken. Especially since most PHP/SQL applications in the wild rarely set up proper SQL user permissions. So most times the attacker can make a dump of your structure and have no need to guess at it.

The only thing I'm sure of is that the script with the connection username/password should not be hosted on the source repository of my choice.

A lot of projects get around this by providing a sample configuration and then through their version control software create a rule that prevents their configuration from being pushed to the version control repository. An example of this is they may have an example config called config-EXAMPLE.php and their setup script renames this to config.php (or creates from scratch) as soon as the information for it is available. And if they are using Github for example include a .gitignore rule to block config.php which will ensure they don't accidentally expose their own configuration.

It is currently not open source, but I am considering making it open source, so that others can fix bugs, improve it...

Don't forget security when making this statement. The best thing about open source is others can spot what you don't and fix or improve on it. And this includes security. Open sourcing your project could potentially fix more security issues than it exposes.

Bacon Brad
  • 3,340
  • 19
  • 26