|
Expert Coming wrote: To answer your question, no that does not solve SQL Injection attacks.
can you give me the example or article as i am pretty sure i looked at lots of articles and did not find any example that it does not solve my problem.
Regards
Shajeel
|
|
|
|
|
Shajeel wrote: but what i want to know is our application safe now,
Not at all. It's will not be safe by replacing ' with ''. There are many other ways a person can inject harmful SQL statements. Look at this[^] which explains these.
|
|
|
|
|
Thanks for reply.
all examples in the article starts with ' which we have dealt with, there are some places where int is used that are not covered here but we are always validating int wherever user enters them in form, so they are covered also. So after going through article i assume my app is safe or is there other ways of SQL Injection which are not included in article.
Regards
Shajeel
|
|
|
|
|
Are you also validating against cross site scripting? This can also lead to a Sql Injection. How?
Well, imagine that you perform clientside validation to ensure that values fall into a certain range. Now imagine that somebody else creates a form that targets your system and doesn't have this validation, then your system can be targeted because the validation has been bypassed. You have to think of security as a whole and minimize the attack surface. One way to do this is to use parameterized queries, rather than relying on your code converting ' into ''. Remember, it just takes this being missed out in 1 place for the whole thing to come crashing down to its knees.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Shajeel wrote: So after going through article i assume my app is safe or is there other ways of SQL Injection which are not included in article.
Always take a multifaceted approach. Just because you can't find a way, doesn't mean that some clever hacker can't find a way. Do NOT be complacent about this. It is arrogant to think that just you put up protection in one area you are safe.
The house my parents live in was very well secured. A burgler attempted to get in the back door, the back windows and eventually got in through the tiny skylight in the roof. Think of your SQL Server the same way. If you secure the main ways in and attacker will find the way you didn't think of.
|
|
|
|
|
Colin Angus Mackay wrote: The house my parents live in was very well secured. A burgler attempted to get in the back door, the back windows and eventually got in through the tiny skylight in the roof. Think of your SQL Server the same way. If you secure the main ways in and attacker will find the way you didn't think of.
Absolutely true. I voted it with '5' vote. 
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
Yesterday is a canceled check. Tomorrow is a promissory note. Today is the ready cash. USE IT.
|
|
|
|
|
Shajeel wrote: all examples in the article starts with '
No, one of the examples began with a number, not a quote:
string sql = "SELECT * FROM Orders WHERE DATEPART(YEAR, OrderDate) = "+
this.orderYearTb.Text);
and the attacker began his string with a zero.
Does seem to me that all the examples I've seen had statement delimiters embedded within them. Therefore, I have two functions I run against the input. The first effectively converts ' to '', but also checks for a maximum length of the argument. If I know the maximum length of the field my user wants to compare against, a string longer than this is rejected outright as a possible attack. The next function removes any unquoted semicolons. This will cause attacking SQL to be ill-formed and rejected for syntax. But DON'T respond to the user with the ill-formed string. They may be able to see thru the protection scheme.
While this two-prong approach defeates every injection example I have ever seen, it does not guarantee, as Colin suggested, that someone clever won't come up with a way to defeat it. Plus, as Pete inferred, the SQL validation (in my case, converting ' to '' and removing unquoted semicolons) must be done immediately before submitting the SQL string to the db for processing. You must not rely on external validation.
David
---------
Empirical studies indicate that 20% of the people drink 80% of the beer. With C++ developers, the rule is that 80% of the developers understand at most 20% of the language. It is not the same 20% for different people, so don't count on them to understand each other's code.
http://yosefk.com/c++fqa/picture.html#fqa-6.6
---------
|
|
|
|
|
Is it possible to compress an MS SQL Server 2005 database, like you can an Access database?
I have a database that is over 100Mb in size but considering what data it currently holds this seems excessively large.
If it is possible, can it also be done with an SQL command?
Thanks
Steve Jowett
-------------------------
Sometimes a man who deserves to be looked down upon because he is a fool, is only despised only because he is an 'I.T. Consultant'
|
|
|
|
|
|
The equivalent in SQL Server is to shrink the database. Have a look at this article[^].
Paul Marfleet
"No, his mind is not for rent
To any God or government"
Tom Sawyer - Rush
|
|
|
|
|
Hi,
Is it wise to make use of indexing?? What are the downfalls of it, won't it slow down my database?
Also, are primary keys indexed automatically? Should foreign keys also be indexed? What else do I need to do to speed up searches?
Please can some advise?
Regards
Brendan
|
|
|
|
|
Indexes speed searches, joins and ordering while they slow down insertions and some updates.
You need to make a balance based on how you access your database.
Stress testing and Database Engine Tuning Advisor[^] can help you make a decision.
Speeding searches does not depend only on good indexes (which are essential) but also depends on using best practices, for example not using a lot of casts and using joins instead of sub queries, joining only needed tables and returning only required columns...etc.
|
|
|
|
|
Brendan - indexes are necessary if you want to speed up your searches. There is a fine balance to strike between having enough indexes to search on and too many - thus slowing down Update/Delete/Inserts.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Hi,
I am going to offer my clients different services. But they need only 1 id and password. What is the best way to go about this, should I have my member tables in a seperate database and each service in a seperate database? I just want to reduce the database if I seperate the databases?
Thanks
Brendan
|
|
|
|
|
I am going to guess that when you say database, you mean table. And if so, then yes, you should have separate tables for both. Maybe something like the following based on what information I digested from your post.
Users -
ID
Username
Password
Services -
ID
Name
User Services -
User ID
Service ID
Where Users houses the usernames and passwords, Services houses the service names, and the User Services simply links which services the user can use.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
|
|
|
|
|
We have sql server replication snapshot index script file (db.idx and db.dat). We want to read data from idx file using c# or vb. Any help will be highly appreciate.
-----
|
|
|
|
|
You are cross posting this in here now!!! 
|
|
|
|
|
I posted here because you said it has nothing to do with ASP.net, what do you want me to do now? do you want me to delete from the other forum? All I want is some tip/guideline? I don't know if your are trying to help or tease?
-----
|
|
|
|
|
I've run across other forums that are not so dominated by "rules tyrants" like here. I'd suggest asking in those forums. I've gotten polite responses from folks at www.dbforums.com
Sorry I can't help you myself. I don't know anything about the subject.
David
---------
Empirical studies indicate that 20% of the people drink 80% of the beer. With C++ developers, the rule is that 80% of the developers understand at most 20% of the language. It is not the same 20% for different people, so don't count on them to understand each other's code.
http://yosefk.com/c++fqa/picture.html#fqa-6.6
---------
|
|
|
|
|
The heading says it all.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
  ;P
-----
|
|
|
|
|
So SQL really isn't my cup of tea and I was poking through the System stored procedures generated by Enterprise Manager at creation-time of a database. While I was looking I noticed a stored proc called dt_validateloginparams. Now, I'm curious if one can use this stored proc to log users into an app or web-app that uses sql login criteria.
I scoured google as much as possible, and only found discussions on how to remove the procedure. Apparently it's not a very popular sp.
Any enlightenment would be much appreciated.
|
|
|
|
|
Will the SQL 2005 client tools allow me to connect to a 6.5 database? I want to run profiler and query analyser. Enterprise Manager for 6.5 is a joke.
Or any other ideas for seeing what is happening, realtime, on a 6.5 SQL database.
"More functions should disregard input values and just return 12. It would make life easier." - comment posted on WTF
"This time yesterday, I still had 24 hours to meet the deadline I've just missed today."
|
|
|
|
|
Dunno avout 6.5, but it works ok on Sql Server 2000....
Regards,
Rob Philpott.
|
|
|
|
|
Try it and see what happens.
Paul Marfleet
"No, his mind is not for rent
To any God or government"
Tom Sawyer - Rush
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
