Securing Code Early

  • Comments posted to this topic are about the item Securing Code Early

  • This was removed by the editor as SPAM

  • When I create a new .NET Core application in Visual Studio and then add it to source control, even though I add the appsettings file to the exclusions list, because VS/GIT adds it initially it is still uploaded to GitHub with all the passwords it contains (although future revisions are ignored) and I have found no easy way to purge it. GitHub provide a (overly complex) list of commands to type to purge a file but when I check online the file is still there so I end up just changing the passwords. Others seem to have the same problem, reading comments online with no clear solution (last time I checked).

    I do think GIT/VS could make this mistake easier to avoid (i.e. auto-excluding web.config and appsettings where passwords are supposed to be held) and then also easier to correct (i.e. purge "name of file").

    My workaround is to ensure the first commit is done early before the appsettings file has any sensitive information and confirm it is excluded on future commits.

    Maybe I have missed something obvious but I do think this could be improved and it might help avoid some of the catastrophes!

    P.S. Had to post this twice as original post disappeared (after editing to add a comma) 🙁

  • Years ago, you could google "filetype:config +uid +password" and get links to 100s of config files located on ftp or even live web servers where the admin didn't properly setup access permissions correctly and it got indexed. In many cases, the server name property contained in the connection string was the actual ip address of the database server and uid was "SA". At some point Google started filtering it out of search results, but some alternative search engines may still. Talk about leaving the keys right there under the door mat...

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Good article, Steve. I've got a few comments about it. First, I completely agree that having more secure code, to begin with, will help prevent problems down the road. However, as a developer and accidental DBA, I can say that it is much harder to implement than one would think.

    I've written more than my fair share of ASP.NET apps with the username and password for a SQL Server database connection hard coded in plain text in the Web.Config file. My bad, although I defend myself by saying it was the only way I knew of storing a database connection. As time went by I learned that you can encrypt the connection info in a Web.Config file. And I've heard of other ways of storing the connection strings in Web.Config files.

    At my current job they're very much into using integrated security, so it all relies upon a person's Windows authentication. This is much better, than how we did it at my previous job. But even here that can cause other problems. Not so much with someone stealing a username/password pair, but with some sophisticated users who want to bypass the system altogether. I'm having to deal with that now, so I'm considering using a dedicated SQL login/user so that these users wouldn't just fire up Microsoft Access, map the SQL tables in ODBC and just go directly against the tables rather than use the app we're developing because, "I know what I want to do so I don't need your app".

    I think the biggest problem is ignorance on a lot of people's part. I've mentioned before that they don't let anyone here go to any conferences or training. That's due to budget. Anyway, not being able to talk with others as to what's new out there, how people are hardening their systems, etc., leads us to not adopt better security practices simply because we do not know. I even went to our chief security officer a few months back, asking him for direction as to how we could better harden our software. He didn't have anything to offer me. A large part of that is because before he got into security, the technology he worked in was PHP, so he doesn't know .NET.

    Along the lines of just plain being ignorant, I've only very recently learned of Azure's Key Vault. I was looking into it, when other priorities pulled me away. And Steve, in your article you wrote, "Can we actually start to teach developers to use secrets and other run-time mechanisms...". Secrets? What's that? I presume its a technology, or at least a paradigm, for better storing things like database connections. Again, ignorance due to lack of being able to get outside of our own environment, is hurting us.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • And thank you for the mention of Sonarqube. I've never heard of it, but looking at it a little bit, it looks like it would be useful.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • There is a lot of work to be done in tooling, and certainly VS and other tools sometimes do a poor job of this.

    There's also more work to be done to point out better examples and update them. We've got issues here, and I can only imagine how hard this is to update lots of content at MS. I'd hope that they would build better reference apps with secure coding ideas, and update the examples people use from docs, but who knows how well they'll do that. I go to conferences and other events, and I still struggle to find good references.

    I've stopped using sa/password1234 or something similar for examples. It's poor design and implicitly gets others to do the same thing. I advocate for and show better practices in examples where I can. If I don't, remind me.

    On integrated Auth, I understand users want to fire up access or Excel or something. I handle those items administratively. I detect them and get a manager to stop them. Other than that, I think it's just better to try and stick with integrated auth mechanisms where possible. It's more secure, and if I revoke something, it doesn't cascade to other people, or I don't forget to revoke an account somewhere. The hassles of people using other tools can be dealt with in another way.

     

  • As far as Integrated Authorization goes, how do you detect that? How can do determine that a user is trying to access tables within a SQL Server database using Microsoft Access or Excel vs. accessing the tables using an application you've written?

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Robin Wilson wrote:

    When I create a new .NET Core application in Visual Studio and then add it to source control, even though I add the appsettings file to the exclusions list, because VS/GIT adds it initially it is still uploaded to GitHub with all the passwords it contains (although future revisions are ignored) and I have found no easy way to purge it. GitHub provide a (overly complex) list of commands to type to purge a file but when I check online the file is still there so I end up just changing the passwords. Others seem to have the same problem, reading comments online with no clear solution (last time I checked). I do think GIT/VS could make this mistake easier to avoid (i.e. auto-excluding web.config and appsettings where passwords are supposed to be held) and then also easier to correct (i.e. purge "name of file"). My workaround is to ensure the first commit is done early before the appsettings file has any sensitive information and confirm it is excluded on future commits. Maybe I have missed something obvious but I do think this could be improved and it might help avoid some of the catastrophes! P.S. Had to post this twice as original post disappeared (after editing to add a comma) 🙁

    Good to know, Robin, thanks!

    Rod

  • Rod at work wrote:

    As far as Integrated Authorization goes, how do you detect that? How can do determine that a user is trying to access tables within a SQL Server database using Microsoft Access or Excel vs. accessing the tables using an application you've written?

    You can trace and see that the application name matches, or doesn't. This isn't foolproof, but it's good enough for most cases. You can even DDL trigger to prevent connections with Excel/Access. Can the user write a .NET app to get in? Sure, but rather than trying to stop them, give them some way to get work done and handle other situations outside of technology.

     

  • You can write DDL triggers to prevent connections with Excel and Access?! I didn't know that! Guess we're going to have to look into that.

    Kindest Regards, Rod Connect with me on LinkedIn.

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply