June 6, 2017 at 9:57 am
David.Poole - Tuesday, June 6, 2017 2:07 AMI'd say we need to hire white hat hackers. I knew one. To say he was greatly unappreciated by the powers that be would have been an understatement.You'd be amazed at what turns up in web and application server logs. You many think you've got your bases covered by encrypting and securing your DB servers. That does you damn all good if someone is writing out "helpful" error messages in clear text containing PII information.
It's difficult for the developer to scrub error message text. Perhaps SQL Server could provide an alternate version of ERROR_MESSAGE(), something more user friendly and safe by default, perhaps call it something like ERROR_COMMENT(). For example, it would contain no reference to the actual object, error code, or other technical jargon but rather a more generalized description of the problem; similar in concept to the default messages we get back from failed connection attempts in SSMS.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
June 6, 2017 at 11:29 am
Eric M Russell - Tuesday, June 6, 2017 9:57 AMIt's difficult for the developer to scrub error message text. Perhaps SQL Server could provide an alternate version of ERROR_MESSAGE(), something more user friendly and safe by default, perhaps call it something like ERROR_COMMENT(). For example, it would contain no reference to the actual object, error code, or other technical jargon but rather a more generalized description of the problem; similar in concept to the default messages we get back from failed connection attempts in SSMS.
The top level application should be responsible for end user messages, not the many subsystems (sql server only being one). Imagine if this principle of subsystems producing UI messages was carried out - maybe you do not approve of the vendors language, or whatever, you would have no control and you would attempt to create un-enforceable demands or even expectations on vendors. So, I think the back end subsystems should do what they do and only what they do - be technical and provide technical and highly descriptive error messages of the exact cause with enough detail for someone to quickly resolve a problem. The front end can log those errors and tell the user, as Microsoft would say, "An Error Occurred".
June 7, 2017 at 5:43 am
The problem is money, human nature, and today's society.
On one hand we have companies and other organizations who to keep the money they have, make more, and make it now. They do not want to invest in their own employment staff, so they contract it out to consulting firms and often are looking at the money as a primary factor. These consulting firms are here for the same reason and using the same methodology as the original company. They in turn search for people who can make them money quickly. The end contracted employee is going to be here for a couple of months and will move on. There isn't going to be pride in the work, and most of the code is going to be just recycled from open source repositories and implementing that. There really is no accountability because the people who provided and did the work will be gone before vulnerabilities are found, and the original organization most likely won't even know that their software has a big red bulls-eye on it.
On the other hand, we have the new "coders". They do not have a strong grasp on any particular item, neither knowing how it works nor the capabilities of it. They really don't need to know it for the task at hand as they can just implement something someone else has already done; either copying and pasting from Stack Overflow or grabbing a repository from GIT. It may not have all the functionality that they want but we can just ask a question and use the code from the first answer to fix that.
And the big enabler are the IDEs that are being created. I don't know about others but Visual Studio and the ORMs have created a development ecosystem that doesn't need an experienced database engineer to create a database nor work with it. We can simply use LINQ & EF to create the structures that we want and tell it to make the database for us and all of the methods that are needed. The ever increasing power of the machines masks the inefficiencies of these methods and it isn't until we pull a 20 gigabyte table that lags to do an aggregate sum that a question gets raised. The "duck" answer to the problem is add more memory (etc) and not looking into it. A simple line of actual TSQL could have fixed that but that is seen as some forgotten language of long ago.
June 7, 2017 at 7:48 am
When it comes to enterprise security, it's also essential that you have dedicated developers, database admins, infrastructure / security, and DevOps professionals. I'll bet that if you look closely at the staff organizational chart of IT departments that have been victimized in major hacks, what you'll see are jack-of-all-trades types in key positions where solid specialization would have been more appropriate.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
June 7, 2017 at 9:58 am
billm 56127 - Tuesday, June 6, 2017 12:04 AMA lot of people are using .Net. The problem is that most .Net developers are more like regular people than they are developers. They don't really understand enough about how code executes to be aware of security holes. They are not "gear heads". To be good at security you have to be able to see security holes while you are coding your own code. A person like that is a thinker, a "gear head". They don't see text on the screen while they are programming, they see behind it. Those kind of people are missing.
I say old chap, I resemble that remark and would strongly refute it. To put it politely.
June 7, 2017 at 10:39 am
MadMyche - Wednesday, June 7, 2017 5:43 AMThe problem is money, human nature, and today's society.On one hand we have companies and other organizations who to keep the money they have, make more, and make it now. They do not want to invest in their own employment staff, so they contract it out to consulting firms and often are looking at the money as a primary factor. These consulting firms are here for the same reason and using the same methodology as the original company. They in turn search for people who can make them money quickly. The end contracted employee is going to be here for a couple of months and will move on. There isn't going to be pride in the work, and most of the code is going to be just recycled from open source repositories and implementing that. There really is no accountability because the people who provided and did the work will be gone before vulnerabilities are found, and the original organization most likely won't even know that their software has a big red bulls-eye on it.
On the other hand, we have the new "coders". They do not have a strong grasp on any particular item, neither knowing how it works nor the capabilities of it. They really don't need to know it for the task at hand as they can just implement something someone else has already done; either copying and pasting from Stack Overflow or grabbing a repository from GIT. It may not have all the functionality that they want but we can just ask a question and use the code from the first answer to fix that.
And the big enabler are the IDEs that are being created. I don't know about others but Visual Studio and the ORMs have created a development ecosystem that doesn't need an experienced database engineer to create a database nor work with it. We can simply use LINQ & EF to create the structures that we want and tell it to make the database for us and all of the methods that are needed. The ever increasing power of the machines masks the inefficiencies of these methods and it isn't until we pull a 20 gigabyte table that lags to do an aggregate sum that a question gets raised. The "duck" answer to the problem is add more memory (etc) and not looking into it. A simple line of actual TSQL could have fixed that but that is seen as some forgotten language of long ago.
I want to piggyback off of what you've said. I work firstly as a developer and then secondly as a DBA, so I have insight into both worlds. And I've been doing this sort of work for a long time. One thing I think we're missing is the different skill levels of people when they wrote whatever legacy app you have to maintain. I'm very mindful of this at this time because I'm having to go back to an old web app that this guy wrote maybe 10 years ago. He wrote horrible code that was very hard for me to figure out, because before he left (and before I came on board) he had his development machine flatten. He didn't bother putting anything into source control, etc. It took me a month of getting backups of the his system restored to various places to try and piece together the source code so I could make the necessary fixes required. And when I had it all together (and now in TFS) I discovered that he didn't do anything that people commonly do with ASP.NET apps. He left important information out of common places (Web.Config, etc.) and just put it into text files scattered around the server. I only discovered this by running the app and seeing where it failed, to see where it was looking for yet another configuration item. Crazy. Truthfully, at the time I thought he was the spawn of Satan.
Then I heard a Dot Net Rocks podcast on maintaining legacy code. One of the first things the guest person said was to accept the fact that the person/people who first wrote the legacy app were doing the best they could, with the knowledge and skills they had and the budget they were operating under with the time constraint they were given. Hey, I now think that this guy just probably didn't know where configuration information commonly went in ASP.NET. I really can't fault him; he was just doing the best he could at the time.
Sorry, that was a bit long. My point is that what would have happened if someone, fresh out of college, were to have tried to piece this together? They would probably have struggled, if they knew ASP.NET. And if all they knew was how to use bower or npm, trying to find the .ini files this code expected to find scattered around the server would have really thrown them. So, is it any wonder then that we have security issues? People's understanding as to how things are to be done, changes over time. Best practices from 15 years ago are irrelevant today.
Kindest Regards, Rod Connect with me on LinkedIn.
June 8, 2017 at 6:26 am
Rod at work - Wednesday, June 7, 2017 10:39 AMMadMyche - Wednesday, June 7, 2017 5:43 AMalotI want to piggyback off of what you've said. I work firstly as a developer and then secondly as a DBA, so I have insight into both worlds. And I've been doing this sort of work for a long time. One thing I think we're missing is the different skill levels of people when they wrote whatever legacy app you have to maintain.
Similiar story here; 30 years of learning the latest and greatest in programming, and due to a an overbearing employer we lost most "server" staff (DBA, IIS, Email) I had to step up and learn everything. Besides my daily duties. No additional pay.
And such timing of my post.... Caught a link to "Is your web developer putting your company at risk?" on Code Project this morning, so I feel someone validated
June 8, 2017 at 7:34 am
It helps if you have tools like OWASP AppSensor.
You don't know what you don't know so anything that automates code inspection is extremely useful. By the time you have learned how to write code to avoid the automated tool lighting up like a Christmas tree and you will have instilled some good base practises and possibly some good advanced ones as well.
Automated tools are also beneficial because they take the personalities out of the criticism. The tool will always apply the same rules to everyone without fear or favour. It will never "cut you some slack" but neither will it get irritated with you or instil paranoia.
The tools are not a panacea but they do stop the bar sinking below a certain point. I find having a floor below which your expectations need not drop a thing of great comfort. Otherwise you don't so much lower your expectations as take them out into the North Staffs coal field and drop them down a disused staff.
git remote add origin thedailywtf.com
June 8, 2017 at 10:09 am
MadMyche - Thursday, June 8, 2017 6:26 AMSimiliar story here; 30 years of learning the latest and greatest in programming, and due to a an overbearing employer we lost most "server" staff (DBA, IIS, Email) I had to step up and learn everything. Besides my daily duties. No additional pay.And such timing of my post.... Caught a link to "Is your web developer putting your company at risk?" on Code Project this morning, so I feel someone validated
This is always an issue. Someone building code with some level of ignorance. We're all in that spot. Even today, the frameworks and techniques we use might be up to date, but they'll age and be insufficient over time. We do need regular maintenance to fix older software.
However, what's the excuse for someone building dynamic, non-parameterized SQL queries in a client application today? We've known for years this is bad, but people still do it. There has to be some bar being raised on how to code better. Current application examples and frameworks should not be doing this. Developers should be learning how to avoid these techniques, and how we do this, I have no idea. I don't know how to get more information out to others, or to get them to understand that some of their techniques are poor.
I can only raise awareness and hope that the needle slowly moves forward.
Viewing 10 posts - 16 through 24 (of 24 total)
You must be logged in to reply to this topic. Login to reply