Thanks for the advice
-
Im relatively new at my company (just over 18 months). I've inherited several legacy apps (ASP classic, all over 7 years old) written by someone who is now a manager in the networking side of the house and in charge of security. I just had to clear my plans for a secure RESTful API through him. IP Filtering, a secure VPN connection, HMAC signature on the request. He then proceeds to poke and prod, why hash and not a public/private key? Why not also use a client cert? Etc. I have no problem with constructive criticism, especially if it can make the application more secure, however it burns me at some level to have this person doing it. Here's a small list of what I've found in his legacy apps: 1. Unencrypted connection strings inline in the ASP file, not in the web.config 2. Inline SQL in the ASP files with no input sanitization or parameterization 3. Try/Catches that do nothing but catch. No logging, no UI notification, just keep going. 4. SQL Accounts (with unencrypted passwords in the file, see #1) that have full dbo owner access to the database. Sometimes I just want to politely, but firmly point out that I would have to actually work fairlly hard to make my applications less secure than the ones he's written. End of rant. I feel better already :-D
-
Im relatively new at my company (just over 18 months). I've inherited several legacy apps (ASP classic, all over 7 years old) written by someone who is now a manager in the networking side of the house and in charge of security. I just had to clear my plans for a secure RESTful API through him. IP Filtering, a secure VPN connection, HMAC signature on the request. He then proceeds to poke and prod, why hash and not a public/private key? Why not also use a client cert? Etc. I have no problem with constructive criticism, especially if it can make the application more secure, however it burns me at some level to have this person doing it. Here's a small list of what I've found in his legacy apps: 1. Unencrypted connection strings inline in the ASP file, not in the web.config 2. Inline SQL in the ASP files with no input sanitization or parameterization 3. Try/Catches that do nothing but catch. No logging, no UI notification, just keep going. 4. SQL Accounts (with unencrypted passwords in the file, see #1) that have full dbo owner access to the database. Sometimes I just want to politely, but firmly point out that I would have to actually work fairlly hard to make my applications less secure than the ones he's written. End of rant. I feel better already :-D
18 months is not "new" ... Apart from that, welcome to the club of taking over stuff written by others. In overall, I am glad these people exist, it means employment for us.
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus Do not feed the troll ! - Common proverb
-
Im relatively new at my company (just over 18 months). I've inherited several legacy apps (ASP classic, all over 7 years old) written by someone who is now a manager in the networking side of the house and in charge of security. I just had to clear my plans for a secure RESTful API through him. IP Filtering, a secure VPN connection, HMAC signature on the request. He then proceeds to poke and prod, why hash and not a public/private key? Why not also use a client cert? Etc. I have no problem with constructive criticism, especially if it can make the application more secure, however it burns me at some level to have this person doing it. Here's a small list of what I've found in his legacy apps: 1. Unencrypted connection strings inline in the ASP file, not in the web.config 2. Inline SQL in the ASP files with no input sanitization or parameterization 3. Try/Catches that do nothing but catch. No logging, no UI notification, just keep going. 4. SQL Accounts (with unencrypted passwords in the file, see #1) that have full dbo owner access to the database. Sometimes I just want to politely, but firmly point out that I would have to actually work fairlly hard to make my applications less secure than the ones he's written. End of rant. I feel better already :-D
Hey! Stop moping and look on the bright side. He didn't leave it prone to HTML injection, did he? :laugh: (Just everything else...)
This message is manufactured from fully recyclable noughts and ones. To recycle this message, please separate into two tidy piles, and take them to your nearest local recycling centre. Please note that in some areas noughts are always replaced with zeros by law, and many facilities cannot recycle zeroes - in this case, please bury them in your back garden and water frequently.
-
18 months is not "new" ... Apart from that, welcome to the club of taking over stuff written by others. In overall, I am glad these people exist, it means employment for us.
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus Do not feed the troll ! - Common proverb
...and we can look good by pointing out the security flaws... ;)
This message is manufactured from fully recyclable noughts and ones. To recycle this message, please separate into two tidy piles, and take them to your nearest local recycling centre. Please note that in some areas noughts are always replaced with zeros by law, and many facilities cannot recycle zeroes - in this case, please bury them in your back garden and water frequently.
-
Im relatively new at my company (just over 18 months). I've inherited several legacy apps (ASP classic, all over 7 years old) written by someone who is now a manager in the networking side of the house and in charge of security. I just had to clear my plans for a secure RESTful API through him. IP Filtering, a secure VPN connection, HMAC signature on the request. He then proceeds to poke and prod, why hash and not a public/private key? Why not also use a client cert? Etc. I have no problem with constructive criticism, especially if it can make the application more secure, however it burns me at some level to have this person doing it. Here's a small list of what I've found in his legacy apps: 1. Unencrypted connection strings inline in the ASP file, not in the web.config 2. Inline SQL in the ASP files with no input sanitization or parameterization 3. Try/Catches that do nothing but catch. No logging, no UI notification, just keep going. 4. SQL Accounts (with unencrypted passwords in the file, see #1) that have full dbo owner access to the database. Sometimes I just want to politely, but firmly point out that I would have to actually work fairlly hard to make my applications less secure than the ones he's written. End of rant. I feel better already :-D
Hm. That he's a manager now might have a reason ;P If he is in charge of the security I think it's pretty much his job to ask you why you'd do it this way to see if you have considered multiple possibilites and if every every requirement gets satisfied. I guess in the end it's also his head if something gets messed up.
-
Hm. That he's a manager now might have a reason ;P If he is in charge of the security I think it's pretty much his job to ask you why you'd do it this way to see if you have considered multiple possibilites and if every every requirement gets satisfied. I guess in the end it's also his head if something gets messed up.
I am all for a security review and suggestions to make anything I'm coding more secure. Sometimes it's just hard to ignore that the person doing the security review never really bothered with it when he was coding.
-
18 months is not "new" ... Apart from that, welcome to the club of taking over stuff written by others. In overall, I am glad these people exist, it means employment for us.
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus Do not feed the troll ! - Common proverb
I've rewritten 4 of the legacy in my "spare time" and the old ones are now gone, as well as a few superfluous web services these app relied on for no good reason. I've got 5 more to go. In 10 years maybe I'll be the person someone is coming on CP to complain about the (then) legacy apps that I wrote :-D
-
I am all for a security review and suggestions to make anything I'm coding more secure. Sometimes it's just hard to ignore that the person doing the security review never really bothered with it when he was coding.
You can learn a lot in seven years, and maybe he would have appreciated some mentorship himself when he was writing those programs. In my experience, programs seldom get updated unless they're broken or lack functionality, almost never because they're badly written.
Be excellent to each other. And... PARTY ON, DUDES! Abraham Lincoln
-
Im relatively new at my company (just over 18 months). I've inherited several legacy apps (ASP classic, all over 7 years old) written by someone who is now a manager in the networking side of the house and in charge of security. I just had to clear my plans for a secure RESTful API through him. IP Filtering, a secure VPN connection, HMAC signature on the request. He then proceeds to poke and prod, why hash and not a public/private key? Why not also use a client cert? Etc. I have no problem with constructive criticism, especially if it can make the application more secure, however it burns me at some level to have this person doing it. Here's a small list of what I've found in his legacy apps: 1. Unencrypted connection strings inline in the ASP file, not in the web.config 2. Inline SQL in the ASP files with no input sanitization or parameterization 3. Try/Catches that do nothing but catch. No logging, no UI notification, just keep going. 4. SQL Accounts (with unencrypted passwords in the file, see #1) that have full dbo owner access to the database. Sometimes I just want to politely, but firmly point out that I would have to actually work fairlly hard to make my applications less secure than the ones he's written. End of rant. I feel better already :-D
I'm with Jorgen on this one, seems to me the guy has learnt a few thing over the last 7 years. Bloody hell I hate to refactor my own code that is 2 years old! Besides it is his job to poke around your concepts and decisions he may also want the reasoning behind your decision so he can continue to learn.
Never underestimate the power of human stupidity RAH
-
I'm with Jorgen on this one, seems to me the guy has learnt a few thing over the last 7 years. Bloody hell I hate to refactor my own code that is 2 years old! Besides it is his job to poke around your concepts and decisions he may also want the reasoning behind your decision so he can continue to learn.
Never underestimate the power of human stupidity RAH
Haha. I might even be afraid of touching code written 2 years ago :laugh:
-
Im relatively new at my company (just over 18 months). I've inherited several legacy apps (ASP classic, all over 7 years old) written by someone who is now a manager in the networking side of the house and in charge of security. I just had to clear my plans for a secure RESTful API through him. IP Filtering, a secure VPN connection, HMAC signature on the request. He then proceeds to poke and prod, why hash and not a public/private key? Why not also use a client cert? Etc. I have no problem with constructive criticism, especially if it can make the application more secure, however it burns me at some level to have this person doing it. Here's a small list of what I've found in his legacy apps: 1. Unencrypted connection strings inline in the ASP file, not in the web.config 2. Inline SQL in the ASP files with no input sanitization or parameterization 3. Try/Catches that do nothing but catch. No logging, no UI notification, just keep going. 4. SQL Accounts (with unencrypted passwords in the file, see #1) that have full dbo owner access to the database. Sometimes I just want to politely, but firmly point out that I would have to actually work fairlly hard to make my applications less secure than the ones he's written. End of rant. I feel better already :-D
Who knows, he had no enough time at the moment he wrote those apps, he didn't knew about those safety features at that moment, now that he has time (and it is his job having time for that) he has documented and read about best methods... Just enjoy doing it and learn... Without knowing the big picture no one apart of himself will know why... Just one question: why the soapbox?
[www.tamautomation.com] Robots, CNC and PLC machines for grinding and polishing.
-
Who knows, he had no enough time at the moment he wrote those apps, he didn't knew about those safety features at that moment, now that he has time (and it is his job having time for that) he has documented and read about best methods... Just enjoy doing it and learn... Without knowing the big picture no one apart of himself will know why... Just one question: why the soapbox?
[www.tamautomation.com] Robots, CNC and PLC machines for grinding and polishing.
Good perspective, thanks. The Soapbox says it is for rants, or complaining about someone. This was a little bit of both.
-
Im relatively new at my company (just over 18 months). I've inherited several legacy apps (ASP classic, all over 7 years old) written by someone who is now a manager in the networking side of the house and in charge of security. I just had to clear my plans for a secure RESTful API through him. IP Filtering, a secure VPN connection, HMAC signature on the request. He then proceeds to poke and prod, why hash and not a public/private key? Why not also use a client cert? Etc. I have no problem with constructive criticism, especially if it can make the application more secure, however it burns me at some level to have this person doing it. Here's a small list of what I've found in his legacy apps: 1. Unencrypted connection strings inline in the ASP file, not in the web.config 2. Inline SQL in the ASP files with no input sanitization or parameterization 3. Try/Catches that do nothing but catch. No logging, no UI notification, just keep going. 4. SQL Accounts (with unencrypted passwords in the file, see #1) that have full dbo owner access to the database. Sometimes I just want to politely, but firmly point out that I would have to actually work fairlly hard to make my applications less secure than the ones he's written. End of rant. I feel better already :-D
-
Good perspective, thanks. The Soapbox says it is for rants, or complaining about someone. This was a little bit of both.
Yes, I guess you are right, typically we put things that are KSS in the lounge, but you are definitely right so... Are you still here? Nothing to see here... move along please... :rolleyes:
[www.tamautomation.com] Robots, CNC and PLC machines for grinding and polishing.
