Researcher’s footnote: An update and some .net static research notes.
A not so quick personal update first: Windows Server Summit came and went about a week back. I learned about Microsoft’s new AZ-800 exam covering hybrid cloud. I’m sure they’ll touch on SDDC technologies and Azure HCI’s direction as their server solution as the future looks more containerized for apps. I’m optimistic about this course and look forward to hearing more on it.
In an interesting change of gears, I decided to make many of my projects public in order to put some of my experience forward. Even though my developer knowledge has barley scratched the surface of what’s possible with code tools, having awareness of how my tooling is developing might help people see my work and gauge interest in taking on new projects. Of course having MVP’s is important too, but one thing at a time here!
This is my first blunder in this area and it’s certainly an educational lesson in how to fix a 3 month old mistake. Covering the resolution in a single sentence isn’t really great, so I’ll link the GitGuardian (not a sponsor) article everyone who gets alerted is shown. [1]
I isolated the incident to a change I pushed backwards: I put the cert files in a staged changed, and then added them to the gitignore for my next change. Whoops! Now I know that’s not how to perform this.
Thankfully this was a key I made for an offline locally signed server, I easily pulled it from my localhost, and safely rolled back the file changes.
Just to be safe though, I redid my process for using git cli, the github vscode plugin, and apps that have access to my github.
This is a great lesson in what it’s like to be on the dev side of adjusting to an incident related to your code. My most recent dotnet project did a good job of scrubbing all the secrets, considering good change control practices offline, and only uploading after carefully looking at the gitignore file. Again big ups to GitGuardian on my account for their resources. Again, not a sponsor, I’m just thankful I did this.
On a lighter note, I’ll be attending the Next.JS update/conference in the audience. Web is one of my passion areas and I’m looking forward to seeing the new and improved features coming from Vercel!
This blog will quickly cover .net default pages. This came from an observation while going through Azure administration coursework. On the heels of OMIGOD, the exploit setting the world on fire a couple weeks back, Microsoft’s prepackaged software solutions are under scrutiny. [1] I’m no stranger to identifying problematic areas where their security could be outlined better. The overall use of pre-packaged code can be troublesome for devs in NPM, Rubygems, and this issue still rings true for the classic NuGet repository.
The tool I was working with while writing an API is Microsoft’s ASP.NET identity configuration sample. It’s good practice to trace public to private strings, and vice versa. This way, you don’t end up passing something that should be kept secret to the user. Additionally specifying the underscore character (_) is just good inline code writing practice. Knowing what is private and becomes public, or what can be modified from public to manipulate private variables, can sometimes lead to RCE, XSS or many of the other dreaded security TLA’s.
RecoveryCodes is stored as a string variable as public, but categorized as temp data. Here we notice we can play with the recovery codes cached within asp and see what kind of nonsense could happen. This is an example of a potential risk. I’m not yet sure how realistic this risk is, but it seems plausible.
I had planned to write on how better solutions were available, but it appears this one is as good as it’ll get for now. Microsoft’s github issues page should be the place to go if anything comes up that isn’t security pressing. Similar to how there isn’t lockout, it can be fun to just throw the details together and see what sticks. [4]
That’s all for now, happy Monday and…
Stay Safe!
[1] https://blog.gitguardian.com/rewriting-git-history-cheatsheet/
