Shouldn’t they have fixed that instead of putting out all these new features? That might be what you are thought when you saw the title for today’s episode. SQL Injection is still a big deal in today’s databases and we are pleased to have Bert Wagner on the program to talk with us about how it can affect you and the applications you protect.
One of the most difficult aspects to deal with SQL Injection is to decide who is responsible for dealing with it? Bert does a great job giving us some insights on what he has seen work and we invite you to give us your comments about how you have gone about trying to evade a SQL Injection attack.
“SQL Injection is essentially when you have a dynamic string that you create in SQL that’s getting executed and it ends up doing something that you didn’t intend to do.”
“When it comes to security it never solely depends on one person.”
“It doesn’t even matter if your database is kind of public knowledge or not, someone is going to be able to guess it.”
“The best thing you can do to protect yourself against dynamic SQL Injection attacks is just get rid of dynamic SQL.”
“Once again injection attacks only can happen with dynamic string execution.”
Listen to Learn
00:04 Introduction of the guest speaker (Bert )
00:38 The famous SQL Injection meme
01:19 What is SQL Injection and possible SQL Injection attacks
02:45 How to know if there is SQL Injection attack in your system?
07:43 Thoughts about dynamic strings, sp_executesql, dynamic SQL
10:38 Dynamic SQL and parameter sniffing issue
16:37 Misconceptions about SQL Injection
23:58 Tips on how to prevent SQL Injection
34:21 SQL Family Questions
About Bert Wagner
Ever since watching hackers first try to break into his website in the late 90s, Bert has been fascinated by the world of security. When not building secure web applications and working with SQL Server by day in Cleveland, OH, he enjoys blogging and vlogging about SQL Server at bertwagner.com. Away from a computer screen, Bert is an avid outdoorsman and all around do-it-yourself-er.
Transcription: SQL Injection
*Untranscribed introduction portion*
Carlos: Bert, welcome to the program.
Bert: Hey guys, thanks for having me.
Steve: Yeah, it’s great to have you on the show. I know we chatted at PASS Summit at our SQL Trail event. I think that was a lot of fun, good to meet you.
Bert: Yeah, it was a lot of fun.
Carlos: Yes, and this is one of the very cool things about having a podcast like this is that we get to have a little bit of a pleasure, right, it’s the Trail Mix and then do a little business as well and talk about our favorite subject which is SQL Server, so we are glad to have you on. Now ultimately, our topic today is SQL Injection and I’m reminded of the meme out there, and it’s a stick figures, but you get a parent or something on a phone and then you see the caption, it’s like, “Why did you name your table or drop table students;”, right?
Steve: Yeah, why did you name your son that?
Bert: It was a famous little Bobby Tables, right?
Carlos: There we go, little Bobby Tables, that’s right. And so that might set the stage a little bit for that idea of SQL injection. Talk to us about SQL injection. What it is and some of the problems and then we’re going to start from there.
Bert: Sure, so SQL Injection is essentially when you have a dynamic string that you create in SQL that’s getting executed and it ends up doing something that you didn’t intend to do, right? A user is passing in some parameter value that is then changing the content of that dynamic string that you built and is causing the query to perform an action that you weren’t originally intending. In essence, that’s what is a SQL Injection attack is, to give an idea from the minor things that can be done obviously. It could be something not very malicious at all. You could inject just random code that won’t really do anything just to maybe test out if the server is vulnerable to SQL Injection or not. Then on the opposite end of the spectrum, you can go all the way to querying system tables to learn more about the data, or querying receiving the full content of other tables. You could modify and manipulate data so it’s not just read-only. It’s really any command that you can think of you can potentially execute through a SQL Injection vulnerability.
Steve: Interesting. Now, with that, I mean if somebody, seems like there are two categories there, one category that could do damage and there is the other category that they are just browsing, and they are borrowing, they are stealing, they are taking some inner data. And I think with that, is there necessarily any way to even know if someone has done that to your system? If there was a vulnerability there to know if anybody ever hit it?
Bert: Right. I mean, so the only way you’d be able to tell is through logging. If you are having users input, free form data into a website or your application which is then maybe kicking off a store procedure, some adhoc query. If you’re logging that information you’d be able to tell. But if you’re not doing that kind of logging then you might not know. It really depends. It’s not just knowing whether you have an injection attack or not becomes a big issue because if you don’t know then you don’t really know the validity of the data that is in your server, right? A lot of times people think SQL Injection, why does it matter and the first big thing that comes to mind is someone is going to steal all our database data. They are going to steal our usernames, our passwords, out highly sensitive data about our customers, and obviously that’s a really big problem, but that’s not the only problem that you get. Like what you’re alluding to, data validity might be a problem if you don’t know that someone is maybe manipulating data on your server. You’re running a shopping cart and they want to give themselves a really good discount so they are updating the prices of your products table
Carlos: Our airline ticket is a little too expensive, right?
Bert: Yeah. I mean, that’s a major problem there if you don’t know what’s happening. There is no guaranteed way of finding out. And then to just round it off, another major issue with SQL injection is just that availability of your server or your application. That’s another thing most people don’t think of is if you’re able to write any kind of SQL code you want and inject it, you could potentially write code that will tie up your server or potentially disrupt access for other users if you just lock everything in the database and no one else can access your app. That’s downtime for your application and that causes another big problem too.
Steve: Yeah, that’s interesting because when people start chasing a performance issue or blocking issue. I mean, very rarely you ever think, “Oh, could it be a SQL Injection attack”, that somebody is messing with you.
Carlos: Right, and to that point along with that so, who ultimately then is the owner of this. Now from our listeners, most of our companeros are data folks in general. We do have some developers out there that listen but I can see this very quickly pointing to into a, “Well, that’s not my problem.” That type of issue. It’s almost like a security issue. No, it’s whoever is writing the start prox issue. And so I guess, maybe we should start digging into, from a DBA perspective, how can I know or which I’ll be looking for to see if SQL Injection is even a problem for me. Is there a good test there?
Bert: Yeah, I guess to answer your first question with finger pointing. I feel like when it comes to security it never solely depends on one person.
Carlos: Sure. It takes a village.
Bert: It takes a village with security. The more layers you have, better off you are typically. And so whether you’re a DBA and you have injectable in a store procedure that’s on one of your boxes, obviously your are responsible for that even though it could be a developer who wrote that could. But it should also be there responsibility to not write this type of code. And then there you could have people if you’re in a large company who has whole groups devoted to security, it should be on their radars too if they are running different pieces of software that profile maybe, types of data that’s going into your servers. It’s on them too. It’s really I don’t think any one person is responsible. I think we are all responsible. And in terms of a few, maybe if you are a DBA and you’re getting a new server. You don’t know what’s on that server. You want to see if you’re vulnerable, right? Because last thing you want is getting an email saying, “Hey, why did you cause our data to get lost?” Yeah, I mean, there are a few different things you could do. None of them are 100% foolproof. You know, I’ve written some scripts on my blog that basically look at various system use that search for queries inside your procedures and functions that may have dynamic string execution occurring. You could pretty easily search the definition of prox and use everything else to see are dynamic strings being executed and then that will help you narrow down where you could start looking to see if you have injectable code.
Carlos: Ok, so I’m looking for “executesql” in my store procedures and then I could start testing there. Is that basically the …?
Bert: Yeah. The reason that’s not foolproof is even though you can say, find me where my definition text is like “execute” or like “sp_executesql”. One, if you find things it’s not necessarily mean that they are injectable. But two, it doesn’t count for all the adhoc queries that might be coming to your server. I mean, that’s only searching your procedures but if a developer has hard coded a SQL query into their app, you’re not going to catch that in the system definitions there.
Carlos: Which I think is not trivial because I think about all the ORMs, right? That’s 90% of what they are doing is creating that code for the developer into the database.
Steve: So just show me back there to the whole sp_executesql place for instance. I mean, one of the things that I ran into a problem a couple of years ago. I was dealing with parameter sniffing issues. And I’ve been to PASS Summit and I thing that was in Charlotte that year and I’ve seen Kimberly Tripp talk about dealing dynamic SQL as a way to work around some of the store procedure parameter sniffing issues you had. I came back and learn from that and adapted some store procedures to it to work that way using dynamic SQL safely with parameters of course. But then immediately everyone jumped on it saying, you can’t use sp_executesql ever because you are going to allow parameter sniffing. Sorry I said that wrong, you are not allowed SQL Injection. And I think that’s one of the sort of misconceptions is that simply using dynamic SQL that’s being executed doesn’t necessarily equate to, yes you are allowing SQL Injection in. Would you agree with that or do you have any thoughts on that.
Bert: Right, so I mean, dynamic SQL exist for a reason. I know, like you’re eluding too, there is a lot of negative I guess association with it because of the injection problem. But there are really good things that you can do with the dynamic SQL like you’re saying, right, parameter sniffing. That’s one way to potentially solve the parameter sniffing problem. There are other things where if you have an application and you need like the ultimate performance to be extracted from it. Sometimes the only way you can get that performance is by writing a dynamic SQL query. Or maybe you need to vary the output of your results set, right? And dynamic SQL is the only way to do it. There is a lot very valid scenarios to use dynamic SQL. It’s just that SQL Injection could be a side effect that you need to be careful of.
Steve: Right, and I think that’s the key there is making sure that where you are using a dynamic SQL that it is safe from the SQL injection perspective.
Carlos: Right, some of the red flags there that you are looking for. Once you’ve indentified a store procedure as being a dynamic SQL like what’s the next step?
Bert: Yeah, so it’s an interesting problem. I personally think that the best way to understand how to protect against it is to fire up your own test database. I mean, don’t do this at work or anything where you might flagged by a security duties at home. Unless you are an info security and that’s your job to test this kind of stuff out. Try it out and that’s the best way you’re going to be able to learn really how it works and how to protect against it. But things you can look for is if you are concatenating parameters into your strings. That’s probably the biggest thing to watch out for because if that’s happening basically you are allowing input data coming from a user, malicious or otherwise, and they are able to append to the SQL string that you’re building dynamically.
Carlos: Ok, so knuckle-dragging Neanderthal that I am. I feel like I have to ask this question just from our previous conversation. The whole reason I’m using dynamic SQL, and very simple example, SELECT * FROM table WHERE parameter = mystore procedure parameter. Right? It will allow people to best set it, so if that’s just one, if it’s equals, it’s ok. But if I’m adding like parameter1 + parameter2, is that where I get into trouble?
Bert: Yeah, so if you think of that exact example you gave where you’re building a string SELECT * FROM table WHERE parameter =, and then that’s all a string and then you’re concatenating in a parameter. That is potentially vulnerable to SQL Injection. And I would argue in that specific example. You shouldn’t even be concatenating a parameter to a simple string like that to begin with. That is a query where you’re parameterizing the value of a WHERE predicate for example. That’s something you can parameterize and use for example sp_executesql t osafely execute. You shouldn’t be using necessarily dynamic SQL to execute that kind of statement to begin with. And that’s a problem that I’ve seen with just people are coming from maybe developer backgrounds not just single amount full disclosure I’m a developer.
Carlos: Oh men! We’re going to have to vet our guest a little bit better, Steve, not just.
Bert: I mean, depending on your background building a dynamic string where you’re concatenating user input values to a query might be acceptable in whatever language you’re coming from. Actually, if your knowledge in that subject is maybe a little older, so it’s not necessarily that people are doing this knowingly or they want to write injectable code. It could just be that their background is that’s the correct way to do it or that’s an okay way to do it, that’s how I’ve always done it. But it’s not necessarily safe secure code.
Steve: Yup, and I think from the perspective of application code that’s making a call into SQL Server. Usually when somebody get started and learns a new programming language or new interface to talk to the database. Usually the examples are there without parameterization, they just show you concatenating something. So when somebody jumps in and just learning it and they haven’t learned the value behind parameters and how to use them. It’s just somebody just doesn’t know any better.
Bert: That’s so true, Steve. I mean, so SQL Injection just as a quick background has been around forever, right? This is not something that’s new. This is not something that’s even in the past decade. This has been around since the 90’s. It’s been around with SQL Server from SQL 6 and 7. It’s been a problem for that long and it continues to be a problem for that long. And I think you’re exactly right. A lot of those beginner tutorials that you follow. They are just trying to teach concepts of here is how to do something or here is how to write a query. And they’re kind of foregoing the whole security aspect of it and that’s unfortunate.
Steve: And whenever I see one of those I always try and go to that next step to understand how to use parameters. Not just from the SQL Injection perspective but also from the performance and reusability perspective.
Carlos: Are there any kind of misconceptions out there that you see around SQL Injection that people are commonly confused with or get wrong?
Bert: Yeah. I definitely interact with people where maybe they are aware of SQL Injection and kind of what it is but they think, “Ok, this doesn’t apply to me for a bunch of reasons.” One of the things I hear is that, “It’s ok. I don’t need to really protect against SQL Injection because the structure of my database isn’t public so my attacker isn’t going to be able to know what to query.” That’s a huge misconception for multiple reasons. One, is that a lot of our databases that we probably use. They have really easy to guess table names and column names, right? A lot of databases probably have a products table or a users table. It doesn’t even matter if your database is kind of public knowledge or not, someone is going to be able to guess it. But then take them step further there is great ways in SQL to find out the structure of your database. Like sys.objects and things like that will just actually tell you that all the table columns in your database. Malicious users know about that and so even if they don’t know the structure of your database they can very easily find it out. Another common misconception I hear them, you know, if I follow up on that is, “Ok, well, I escape my table names”, which I hope you don’t do that. But once again, using something like sys.objects, sys.columns is going to reveal that information. So it doesn’t matter if you columns are called A1, A2, A3. To a hacker or someone trying to get your data it’s not going to stop them all.
Carlos: Now having said that, if, that’s a big if, you’re using an application user that just has read and write to that database. Don’t those objects then no longer available?
Bert: Yes, that’s a great point, Carlos. That’s one of when I’m trying to write secure code and trying to protect an application from SQL Injection. You know, that’s one of the number one things that you want to do for all your code that you’re writing, that’s accepting user input parameters is lockdown that user that’s executing the code to kind of minimize damage. It still might not fully protect you from SQL Injection but it’s going to limit what that malicious user is able to find out or do in your database.
Carlos: Right, so they are going to work a little bit harder which may or may not be their prerogative.
Bert: Right. I mean if you take that user and you only give it read access, there is no way they are going to be able to modify data, delete data, anything like that on your database. They might still be able to read the contents of a table but it will be limited to that table or that schema or that database depending how well you protect that log in there.
Steve: So one of the misconceptions that I came across. I’m just curious what are your thoughts on it might be. But around, let’s say it’s a web system and there’s thousands of webpages that are accessing the database and you got to go through obviously make sure that everyone of those is SQL Injection safe. But one of the misconceptions that I experienced in a management situation was that we found there were SQL Injection problems in a system. We presented it to the management team and their response was, because there were two pages in the site. There are pages that you can see before you actually log-in to the system and there are the pages you can see after you log-in to the system, so we know who you are. And the response was just, “Well, let’s just make sure all the pages that you don’t have to be logged in to see.” And this is a public site used by thousands of people across the world. But let’s just make sure the pages that are public that don’t require a log-in are SQL Injection safe. We’re not going to worry about the other ones because those are log-in users and they would never do anything like that.
Bert: Yeah. I mean, there are a bunch of red flags there, right? But yeah, I mean, you need to protect against SQL Injection everywhere. It depends on your application but I’m sure many people have created multiple Twitter accounts or multiple Facebook profiles. So what’s going to stop someone from creating a fake account into that system, right? And even though they are logged in it doesn’t mean anything. People who want to get into systems are really good at kind of covering their tracks. It doesn’t matter if they are authenticated into your app there unless you’re tying your users to their passports or something like that. You got some very high secure verified application where you’re not just letting anybody register. But even then you still want to protect against injection.
Steve: Right. And this is one where anyone could just sign-up for a demo account or trial account in the system they were in.
Bert: Yes, that’s a big red flag especially because nowadays, it used to be that, another misconception I’ve heard a lot is, “My website, my application is so small. No one would ever try to attack me.” Like I’m selling boutique garden gnomes online and I have 50 costumers a year and they are all really into garden gnomes. I know none of them are malicious, right. The fact of the matter is that it’s not like someone needs to be actively searching for injection vulnerabilities on your site by hand. Like going in to the log in form and trying different things. There are plenty of tools that hackers have to automate that kind of attack and they basically just go scan the internet and having these tools automatically test for injection vulnerabilities just to find which sites out there have them so they can potentially get the data and do various things with it.
Carlos: Yes, scary stuff.
Bert: Yeah, but it’s also cool. So like one of the tools I want to mention is called SQLMap. It’s an open source tool that’s used for automating SQL Injection testing. If you have an application and you really want to test it out, you don’t have to use these kinds of apps. These apps work kind of both ways. They help out the attackers but they also going to help you out on the defensive side to actually test your own applications to see very quickly and easily is my application vulnerable to SQL Injection attacks, so works both ways.
Carlos: Right, very cool.
Steve: Well, I guess if you’ve got someone who‘s listening and maybe this is their sort of first exposure to SQL Injection, the topic of SQL Injection. Is there anything that you might recommend or any tips you may have that may help with preventing it. Like where you would start first if this brand new to you?
Bert: Sure, so usually this is kind of how I evaluate and try to protect against SQL Injection. First thing is, do I need to be using dynamic SQL? Because like we kind of talked about earlier, a lot of times it could just be someone wrote a query that’s dynamic and is concatenating parameters because that’s just the only way they know how to do it. But if you’re just concatenating a WHERE predicate value, you don’t even need to be doing. Then just get rid of your dynamic SQL. You could just pass in a parameter to your query and it will evaluate perfectly fine without needing to build a dynamic query string. So honestly, that is by far the best thing you can do to protect yourself against dynamic SQL Injection attacks is just get rid of dynamic SQL. Always the first thing to check is do you actually need to be using dynamic SQL?
Carlos: Yeah, why was this put in place?
Bert: Just kind of a common sense sanity check. Can I write this a different way and still get the same result without making myself vulnerable because once again injection attacks only can happen with dynamic string execution. If you don’t have that dynamic string execution, you’re good to go.
Carlos: Sure. I guess I do want to make one point where we’re kind of talking about, you know, everybody needs to pay attention. One additional that I had and Troy Hunt was talking about this. This is more of the SSL certificates on small sites. But the idea was that, yes they may not, going back to the garden gnomes. They might not be trying to attack your site but they may be trying to get into your site to then send malicious stuff to somebody else. And that’s even bigger problem because now you get blacklisted and so your 50 customers go to 0. Who’s going to blacklist you and all other stuff.
Bert: Right, that’s a huge, that’s a great point. That was a great blogpost from Troy Hunt there about that. And just SQL Injection in general if you ever want to know numbers, that’s hard to get numbers, but Troy Hunt runs this website “haveibeenpwned” Which if you’re not sign up for, you should. It’s basically a notification and service for your username and data breach that gets exposed. But if you go to their data breach page there you can just do like a CTRL + F find on the webpage and search for SQL Injection. And you will see all of these companies, huge companies. I’m talking like Yahoo! and Sony who specifically have data leak because of SQL Injection attacks. This is like a really serious deal that affects everybody. Sometimes it’s nice, I mean not nice, it stinks for those companies, right, for their users data get released. It’s not just you by yourself. I mean this is a major problem that affects everybody.
Carlos: I agree. And then of course if you are subject to it, that’s not fun. That’s not fun for the managers because you don’t know the extent of it. You may not even know where it is. So then all of a sudden they are kind of throwing money at a problem to try and stop it and they don’t know it’s not worth going.
Bert: Yeah. I mean, so you want to do your best bet. And so option one is just get rid of that dynamic SQL if you don’t need it. After that, let’s say you evaluate your app and you do need dynamic SQL. Like you’re doing one of those things that is valid to use dynamic SQL in your database. The thing you would want to try to do is do something like sp_executesql which will parameterize your dynamically built queries. And so that is the safe way to allow input parameters that you pass in and executed as part of a dynamic SQL query string without falling vulnerable to that injection attack. Now, sp_executesql has its downsides though. Although you can pass in a dynamically generated SQL query into it to execute, you still can parameterize everything with it. So things like table names, right? You wouldn’t be able to pass in as a parameter even if using sp_executesql, it won’t work. A lot of times a table name might be something that you do want to parameterize.
Steve: Oh, and that’s an interesting one. Do you have a good option for how to do that?
Bert: Yeah. The best option would be to use the QUOTENAME function in SQL Server. And that just basically escapes characters by default. If you don’t pass in any parameters besides just the string that you’re escaping at as brackets around it kind of make it a system object name, and that will protect you for sure. The downside to using QUOTENAME. So QUOTENAME is the best solution if you can’t use sp_executesql. The downside is that it is limited to outputting only 128 characters. So if your input for some reason is longer than a 128 character, you need to start getting a little creative with what you do and that opens you up to potential problems.
Carlos: Right, then you start concatenating and putting all these things together. Yeah, you’re kind of back to square one.
Steve: So there is one example I saw where they are passing in a table name that needed to be concatenated in to a string. And there are only 5 or 6 options, 5 or 6 possible table names they could pass in. So the solution they came up with was instead of just concatenated them, it put inside of an if statement that is said, if it’s table name1 or table name2 or table name3 it injects not parameter but the actual text of what that table name was. If it doesn’t match one of those known table names it falls through and aborts of the store procedure.
Bert: And that’s, I mean if you’re able to do that, that is great. And that’s not just on the DBA side but if you’re working with your developers the first line of defense for these types of attacks is the developers. It’s the app code. They should be doing all these things too. They should be sanitizing their inputs. They should be checking that the input data is a valid entry. Like if there is only 6 table names, it should be one of those 6 names and then if you’re able to do that similar kind of check with an if statement in T-SQL then all the better. The problem starts to crop up when you have a more complex input, quantity of values that you’re inputting. If it’s 6 tables or 10 tables it’s pretty to handle. But once you get to the realm of many more than that and you start wanting to write maybe what at that time seems smarter validation functions or sanitizing functions that’s where you get yourself into trouble because it’s really hard to write a function that’s 100% secure that kinds of validates data like that.
Steve: Very good point.
Bert: And so what I’ve seen a lot is people will use like the replace function for example. Once common technique to prevent SQL Injection is to sanitize your input from single quotes, right? Because if you are trying to inject some code, usually that injected code is going to use a quote in it somewhere to end one statement and help start another statement. So what people will do is they will try to write a REPLACE function that replaces single quotes with a set of two single quotes to kind of escape that quote and prevent the attacker from succeeding what they wanted to do. While that works great for some scenarios, it doesn’t work in all scenarios. That’s the big caution with trying to kind of write your own sanitation functions in SQL Server using something with REPLACE because it’s not always going to work. And it’s not always right to think of every scenario that an attacker might try is impossible. Even if you’re somehow able to do it that doesn’t mean that some new feature of SQL in the future is going to stay on top of that forever whoever ends up maintaining your code. That’s just really a big problem there. And like we mentioned, locking down the user account that is executing your SQL queries makes a big difference. That’s something I would implement in all scenarios for sure.
Steve: Oh yeah. I don’t know how many times I’ve seen the web system at places that runs as the SA user. That’s one of the first things I always want to get changed because it’s just so dangerous.
Carlos: Oh yeah.
Bert: Yeah. I mean, that opens you up to everything.
Carlos: Should we go ahead and do SQL Family then?
Steve: Let’s do it.
Carlos: So Bert how did you first get started with SQL Server?
Bert: Well, I started my database expeditions in MySQL probably when I was 11 or 12 years old.
Carlos: Oh, starting young.
Bert: Yeah, just running a PHP website, coding my own log, having tons of SQL Injection vulnerabilities there and that’s actually where I learned. That’s why I learned about SQL Injection was actually with MySQL. I would look at the logs and say, “Ok, what’s all this weird 1=1 input that people are submitting.” That’s my start with databases. I obviously didn’t know much back then. I still don’t think I know much now but that kind of open the doors to get hired to a Microsoft shop where they have SQL Server. Yeah, sure, I know all about relational databases. I’ve built websites using MySQL and so that’s kind of how I got started there.
Steve: Pretty cool.
Carlos: If you could change one thing about SQL Server, what would it be?
Bert: Well, if you had asked me this question a year ago I think I would have different answers. But I’ve been really impressed with how kind of the speed of development has become with SQL Server in the past year. Like that would be my big wishlist item would have been just get more features out faster. It seems like they are doing that. I’m really satisfied with that. I guess the one thing I still like to change is for them to take like a release. Maybe not a major release but just take the time and really polish the existing things that are in there. I’m talking about things like maybe making error messages more user friendly instead of just telling me some data got truncated. Point me to that data so that I know so I don’t have to figure it out on my own. Or if I run out of space.
Carlos: Which line? Dang it!
Bert: Yeah. You know, for me if I’m using a tool everyday those little kinds of things make a big difference into how happy I am and how happy I am to use a tool. So that would be huge for me because I mean all the features are great. I’m happy with them. Mitch is polishing all the rough edges would be great.
Steve: Ok. I like that.
Carlos: What’s the best piece of career advice you’ve received.
Bert: My favorite career advice that someone told me once is I guess the popular one is, “Fake it till you make it.” But someone kind of has their own modified version. There’s this photographer chase Jarvis and he always talks about “Make it till you make it”, which basically just keep doing what you’re doing and eventually you will get to where you want to be just by kind of continuously improving and getting better at whatever your craft is, right? In his case it was photography. But for me it’s like I want to become better at SQL Server. The only way to do that is just to keep doing things with SQL Server, pushing myself to learn new things and blogging.
Carlos: Making mistakes and then learning from those mistakes. That’s the big thing, right? The fear of failure can hold us back sometimes.
Bert: Right. I mean, hopefully don’t do any injection mistakes in production but always get to learn.
Steve: Ok, so our final question. If you could have one superhero power, what would it be and why would you want it?
Bert: So thinking about this, I think I would want to be able like to control time. Not like be able to go back time to 10 years or 20 years or something like that. But if there is like an undo button for where I could just kind of go back in time some limited duration like maybe three minutes or five minutes. Not only will that prevent lots of “Opps” scenarios where I delete something that I don’t want but I guess I could always put in those last minute bets to in crazy sport events outcome that no one expects. I think that would be pretty cool. Then you don’t have to deal with all the ramifications of changing history and the whole future outcome is different. So I think three minutes back wouldn’t be too bad.
Steve: Ok, so the time control undo stack. I like that.
Carlos: Well, awesome. Well Bert, thanks so much for being on the program today. We do appreciate it.
Bert: Yeah, thank you guys. It’s a pleasure.
Steve: It’s great to have you Bert. We learn some things along the way, too.