May 10, 2012 at 7:37 am
Perry Whittle (5/10/2012)
hisakimatama (5/9/2012)
I'm not sure what the distinction is there, Perry; I'm assuming Windows form would mean something coded in a language such as Java, C#, C++, etc.? Either way, I believe it's coded in a non-web-based languageWhat do you mean web based language? Asp.net web pages still use either vb.net or c# in their code behind pages.
A web form is a website and a windows form is a windows dialog based application.
The point I'm making is that data may be validated at the point where it's entered. For instance, an input text box may have validation rules coded in the application or may even be using .net validations to ensure that what is passed to the SP is valid. There may be a validation check for certain characters such as -- and " and ; etc.
Doing some text replacement is not even close to good enough. Hex attacks can be more difficult to detect using typical text replacement methods. The ONLY way you can be certain you are safe from sql injection is to never execute user entered information without the use of parameters.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
May 10, 2012 at 7:54 am
Ah, I understand now, Perry. The application is certainly a Windows-based application, then. There is no text validation present that I can discern, though; all special characters that I tested in relation to SQL server (@, ;, '', --, *, %, etc.) are readily accepted by the entry forms in the application.
The biggest issue with the application is partially related to this problem, though. The reports that a user could get from the application used to be quite helpful and detailed, but they were a source of SQL injection attacks (as the WHERE clause to determine what the report should display would accept any user input). As a result, the reports were more or less entirely dismantled from the system, and only six remain, though three of them are still vulnerable to injection attacks. Without the rest of the reports, it's not possible to get good metrics on sales, ordering, accounting, or most of the other vital details our business would need. Since the company chose to simply remove functionality that was vulnerable, instead of fixing the vulnerabilities, the crucial data most users need isn't even accessible anymore.
- 😀
May 10, 2012 at 9:00 am
hisakimatama (5/10/2012)
The application is certainly a Windows-based application, then.
so it's not exposed to the "outside world" then.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
May 10, 2012 at 9:23 am
Perry Whittle (5/10/2012)
hisakimatama (5/10/2012)
The application is certainly a Windows-based application, then.so it's not exposed to the "outside world" then.
Sure, and there is no way to get onto the server/pc its running, as it's running disconnected from any network...
But, if you have a cable connected to the network card, there is always a way to get into it from outside, it just requires relevant skills...
May 10, 2012 at 9:27 am
Eugene Elutin (5/10/2012)
Perry Whittle (5/10/2012)
hisakimatama (5/10/2012)
The application is certainly a Windows-based application, then.so it's not exposed to the "outside world" then.
Sure, and there is no way to get onto the server/pc its running, as it's running disconnected from any network...
But, if you have a cable connected to the network card, there is always a way to get into it from outside, it just requires relevant skills...
...Or be a disgruntled employee...
And of course as soon as you have a proc that is for "internal use only" somebody working on a new website will remember there is a proc that does "x" already and will reuse it. Now your "internal use only" proc is exposed to the world.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
May 10, 2012 at 10:53 am
Actually, it's somewhat exposed to the outside world. It's cloud-hosted, and several other clients are on the same server instance as us. If we choose to upload data to the cloud platform, we can see the other database instances belonging to the other clients (of which there are five besides us), and we can even poke around in their server folders a bit, as my boss discovered. It's a VERY unsecured platform, in my opinion, and it flat-out violates most of the security rules that should be in place with this sort of a program.
On top of that, I don't believe we even have separate databases, to be honest. I've noticed that data that we input into the system ends up being flagged with our account name, and that account name is used as part of the WHERE clauses when reads are done so we only pull back data from our account. However, customer support has told us that a big part of why they don't want us doing custom work unless we move to a single-user dedicated platform is because we're sharing the dataspace with the other clients on our platform, which leads me to believe that their data rests in the same tables, flagged with their account names, and our WHERE clauses are specifically tailored so we won't stumble into their data. This falls apart when they have injection-vulnerable queries, though.
For that matter, if my understanding is correct, if a company hosts a cloud-based database, each database should be firmly locked down with proper permissions, and access to other users' data shouldn't even begin to be possible, correct? I'm still farily new to the programming world (been at it for almost a year now), so there's probably bits and pieces here that don't work how I think they should, but I'd like to make sure.
- 😀
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply