By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,850 Members | 970 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,850 IT Pros & Developers. It's quick & easy.

SQL Injection - Stored Procedures

P: n/a
BTR
I have been working on this particular project for a little over 2 weeks now. This product contains between 700-900 stored procedures to handle just about all you can imagine within the product. I
just personally rewrote/reformatted close to 150 of them myself. Nothing too fancy, mostly a lot of formatting. We have a little down time between Q/A and fixing any bugs they find so I decided to
test the security of the site with Cross-Site Scripting and SQL injection. Because SP's are used in pretty much every aspect of the site, the site isnt vunerable to the simple Injection stuff like '
OR 1 = 1 . Instead I've had to try several things which I will get to in a minute. As I have access to all of these SP's and the dB in which they reside, I could easly look at the code and determine
what variables are neede to pass in. I've been trying to break the site to give up a database name so I can proceed to check the system tables etc etc - much like a regular hacker would (meaning not
cheating by looking at the code). So, I've started my attack by downloading a local version of the login page, changing a few variables and injected somthing like:
'SELECT * FROM INFORMATION_SCHEMA.TABLES

Initially, the statement is passed into the form fields and wont return anything other than a JS popup error. I altered the statement intentionally to break the page
SELECT * FROM INFORMATION_SCHEMA.TA'

and it produces an error giving me the name of the query and its location
when I plug the name of the query in the url i.e http://theurl.com/query_folder/query_name/ it fires me off to another folder containing an include file of some sort.
When I run that include it gives me the name of a pretty important variable. Apparetly its a variable that determins what dB I should point to.

Now, one of the issues I have is that everything is a stored procedure so trying to hack it is a little more difficult. But because I have the SP name and one of the variables its needs (found through
lots of testing) I've been trying to construct something that will throw an error to produce a dB or table name. The attack looks something like this:
'SET @var2Exec = 'DECLARE @var1 VARCHAR(2000); DECLARE @var2 INT SET @var1 = ''SELECT * FROM INFORMATION_SCHEMA.TABLES'' SET @var2 = 12345 ; EXEC(@var1)'
'EXEC(@var2Exec)'

I will always return an error saying that @var2 is of the wrong type etc. Essentially this means that I am passing in 2 variables to a SP that requires more than 2. So my question is, does anyone know
of a way to exploit the nature of Stored Procedures? It can be done, but my knowledge of SQL Injection is pretty limited but was wondering if anyone tests their own sites in this manner. Any
suggestions would be greatly appreciated.
Jul 22 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
BTR
On another note I've read a few posts that others have had dealing with SQL Injection. Honestly there are 2 things you should be concerend about. SQL Injection and Cross Site Scripting. Often they are
used in combination with one another.

SQL Injection is most easily defeated using regular expressions to validate all of your data. While JavaScript is fast, Server Side is better, especially when validating for sensative data. You can
strip out most characters that make SQL injection easier. You wouldnt ever have a " or a ' in a password field, so why allow it? Regular Expressions can easly shut down an attack. Another way is to
set up a custom error page. Why give the attacker any more information than needed. If an error is detected - fire them off to a custom error page that says sorry we cannot .... dont give them access
to the ODBC errors that list the table names etc. Its not fool proof but it closes another open door to an attacker.

Cross Site Scripting or CSS is the ability for a person to download a local copy of the form or even a cookie, alter its contents, and then submit it from their browser to the live site. This can be
an issue (especially in shopping carts) where an attacker can submit a false value to your form processor. The data will be valid but its value is wrong. I deal with this by checking where the
referral page is. Especially when dealing with shopping carts Page 1 will be sent to Page 2 - Page 2 checks to see if the info came from Page 1 or originated somewhere else.

These are a few really simple things I do to help keep my sites safer. You should really learn to hack your own sites. It makes you a better coder in the end.

P.S. it is possible to exploit Stored Procs - but it takes a hell of a long to time to do it.

~Bastard
Jul 22 '05 #2

P: n/a
BTR wrote:
that requires more than 2. So my question is, does anyone know of a
way to exploit the nature of Stored Procedures? It can be done, but
my knowledge of SQL Injection is pretty limited but was wondering if
anyone tests their own sites in this manner. Any suggestions would be
greatly appreciated.


One of the values you get from stored procedures is resistence to SQL
injection. I say resistence instead of protection because you can still
expose yourself to risk if you do something dumb like this:

EXEC @DynamicSQLBuiltInMyProcedure

Without dynamic execution, parameters insulate you from injection. One thing
I note is that you have not provided details on your interface. How you
construct your SP call is a potential point of vulnerability, such as:

CN.Execute("MySP " + ParameterList)
Also, a bit of error handling goes a long way toward protecting the details
of your scripts and your DB:

try {
RS = CN.Execute( ... )
} catch(e) {
SendErrorEmail(e)
Page.Message = "Error accessing data"
}
All examples in JScript, obviously.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Jul 22 '05 #3

P: n/a
BTR wrote:
SQL Injection is most easily defeated using regular
expressions to validate all of your data.
Not really. I can use ADODB.Command and NEVER validate any data, and still
be 100% protected from SQL injection.
While JavaScript is fast, Server Side is better,
especially when validating for sensative data.
If you are going to validate at all, you must do it on the server. Doing it
on the client is an acceptible complement to server-side validation, but it
can never replace it for any reason.
You wouldnt ever have a " or a ' in a password field,
so why allow it?
WTF are you talking about? I use " and ' in passwords all the time, not to
mention > and < (one of our vendor apps disallows these, to my great
annoyance). Forbidding those characters is an advertisement of your own fear
and incompetence. IMO, the data in the DB should be the data entered by the
user, subject to the constraints of the DATA TYPE (not by your programming
limitations).
I deal with this by checking where the referral page is.
Especially when dealing with shopping carts Page 1 will be sent to
Page 2 - Page 2 checks to see if the info came from Page 1 or
originated somewhere else.
Easily defeated: http://livehttpheaders.mozdev.org/
P.S. it is possible to exploit Stored Procs - but it takes
a hell of a long to time to do it.


On the contrary. I find it easy to make stored procedures unexploitable. The
first 5 things that some to mind:
1. Take away SELECT, UPDATE and INSERT rights from your application's SQL
Login. Grant execution permission on a procedure-by-procedure basis
2. Use error handling
3. Coerce values into their expected sub-types before assigning to
parameters
4. Use ADODB.Command objects (or at least escape single quotes for string
parameters)
5. Swear off dynamic SQL string construction and execution forever
--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Jul 22 '05 #4

P: n/a
BTR wrote:
I have been working on this particular project for a little over 2
weeks now. This product contains between 700-900 stored procedures to
handle just about all you can imagine within the product. I just
personally rewrote/reformatted close to 150 of them myself. Nothing
too fancy, mostly a lot of formatting. We have a little down time
between Q/A and fixing any bugs they find so I decided to test the
security of the site with Cross-Site Scripting and SQL injection.


If you pass arguments via the Parameters collection of the Command object,
or using the procedure-as-connection-method technique
(http://tinyurl.com/jyy0), and you do not use the parameters to build
dynamic sql statements inside your stored procedures, then you are
invulnerable to sql injection. Period. SQL Injection depends on the use of
dynamic sql. Without dynamic SQL, there can be no SQL Injection. More:

http://mvp.unixwiz.net/techtips/sql-injection.html
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=23
http://www.nextgenss.com/papers/adva..._injection.pdf
http://www.nextgenss.com/papers/more..._injection.pdf
Validation techniques can be defeated, although the time it takes a hacker
to defeat them may cause him to move on to a more vulnerable site. So:
always validate in server-side code to avoid CSS exploits. Client-side
validation should supplement the server-side validation, not replace it. The
only reason to use client-side validation is to provide a better user
experience, allowing data entry errors to be causght immediately rather than
after submission.

Bob Barrows

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
Jul 22 '05 #5

P: n/a
BTR
Most of the formatting I did with this project was to take these Huge Dynamic SP's and de-dynamicise them into compiled queries. This meant taking the branching logic and hardcoding all of the
possible combinations for that query. This was done because:
1. Some of these SP's are hit over 1 million times a year. That is a huge amount of overhead on the Server, this server contains 2,000 databases.
2. The branching logic If ElseIf Else slows things down with dynamic queries that are close to 200 lines long and have 2 dynamic elements in them.
3. Some of the SP's were returning temp tables full of information in the dynamic portion of it.

Dynamic SQL makes for nice looking coding but in the case of this project, we took a Dynamic SQL SP and compiled several children SP's and referenced it from a Parent SP. The result was a SP that took
over 1 minute to compile to one that ran in less than 1 sec. So the benefits to compiled Queries is considerable, but a little harder to maintain.

Now I know that these queries that I am trying to hack have variables passed into them. So

the SP would liike
Create proc 1
@var INT
AS etc etc.....

The idea of the attack is to pass in another variable that contains the SQL statement. The idea being that @var1 is set to equal something in the SP. If I could make it equal the SQL statement I am
passing it, it should begin to open up some information for me. That is what I'm currently trying to accomplish. I've already read 3 of the links you gave in their entirety.

A little goes a long way when dealing with SQL Injection and Cross Site Scripting (which doesnt seem to get too many people concerned for some reason). Yes, while validation is not fool proof, very
few things are in this world are, but at the same time the benefits of doing it over not doing it are considerable. There is no reason what so ever that you would want to leave those doors open.

I'll let you know more about the process if anything new comes up.

~Bastard
On Thu, 17 Feb 2005 06:52:16 -0500, "Bob Barrows [MVP]" <re******@NOyahoo.SPAMcom> wrote:
BTR wrote:
I have been working on this particular project for a little over 2
weeks now. This product contains between 700-900 stored procedures to
handle just about all you can imagine within the product. I just
personally rewrote/reformatted close to 150 of them myself. Nothing
too fancy, mostly a lot of formatting. We have a little down time
between Q/A and fixing any bugs they find so I decided to test the
security of the site with Cross-Site Scripting and SQL injection.


If you pass arguments via the Parameters collection of the Command object,
or using the procedure-as-connection-method technique
(http://tinyurl.com/jyy0), and you do not use the parameters to build
dynamic sql statements inside your stored procedures, then you are
invulnerable to sql injection. Period. SQL Injection depends on the use of
dynamic sql. Without dynamic SQL, there can be no SQL Injection. More:

http://mvp.unixwiz.net/techtips/sql-injection.html
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=23
http://www.nextgenss.com/papers/adva..._injection.pdf
http://www.nextgenss.com/papers/more..._injection.pdf
Validation techniques can be defeated, although the time it takes a hacker
to defeat them may cause him to move on to a more vulnerable site. So:
always validate in server-side code to avoid CSS exploits. Client-side
validation should supplement the server-side validation, not replace it. The
only reason to use client-side validation is to provide a better user
experience, allowing data entry errors to be causght immediately rather than
after submission.

Bob Barrows


Jul 22 '05 #6

P: n/a
BTR
On Thu, 17 Feb 2005 00:46:42 -0600, "Dave Anderson" <GT**********@spammotel.com> wrote:
BTR wrote:
SQL Injection is most easily defeated using regular
expressions to validate all of your data.
Not really. I can use ADODB.Command and NEVER validate any data, and still
be 100% protected from SQL injection.

You have to realize that alot of the poeple here are not SQL experts. Most everyone learned SQL by creating these dynamically built SQL strings including myself. I've just recently started working
with SP's. RegularExpressions are a great defense against SQL injection and a great way to validate data before it goes into the dB. Just because you validate your data in the SQL (if you even do
that) just means you have to write more SQL and depending on what you're doing with it could slow things down. The idea of building a secure website is closing open doors, and layering the
protections. The more layers the less likely an attacker is going to stick around.
While JavaScript is fast, Server Side is better,
especially when validating for sensative data.
If you are going to validate at all, you must do it on the server. Doing it
on the client is an acceptible complement to server-side validation, but it
can never replace it for any reason.

Agreed
You wouldnt ever have a " or a ' in a password field,
so why allow it?
WTF are you talking about? I use " and ' in passwords all the time, not to
mention > and < (one of our vendor apps disallows these, to my great
annoyance). Forbidding those characters is an advertisement of your own fear
and incompetence. IMO, the data in the DB should be the data entered by the
user, subject to the constraints of the DATA TYPE (not by your programming
limitations).

Its easy to say WTF on something like this, especially if you work on sites with a small user base and they have an inkling of what they are doing in life. However, this particular project and many I
have had in the past have a user base of 500,000+ users. The #1 call tech support gets is What is my password? It is generally thought that to keeps costs and the amount of phone calls down, limiting
the characters allowed in the PW field to numbers and characters was the user friendly way to handle it.
I deal with this by checking where the referral page is.
Especially when dealing with shopping carts Page 1 will be sent to
Page 2 - Page 2 checks to see if the info came from Page 1 or
originated somewhere else.
Easily defeated: http://livehttpheaders.mozdev.org/

So I suppose, you would just rather not do it? Just leave that door wide open and allow an attacker to CSS your site because something can be easily defeated so you say? No site will ever been
bulletproof. But I think its wrong to say Dont do something because its easily defeated or takes a special tool to do so.
P.S. it is possible to exploit Stored Procs - but it takes
a hell of a long to time to do it.


On the contrary. I find it easy to make stored procedures unexploitable. The
first 5 things that some to mind:
1. Take away SELECT, UPDATE and INSERT rights from your application's SQL
Login. Grant execution permission on a procedure-by-procedure basis
2. Use error handling
3. Coerce values into their expected sub-types before assigning to
parameters
4. Use ADODB.Command objects (or at least escape single quotes for string
parameters)
5. Swear off dynamic SQL string construction and execution forever


Not all developers are dB admins. In fact is most case I've been involved with, the dB servers are run by other people, some smart (will limit who can run what SP, preventing escalation) and others
are not (in one case cant even set up a FTP server properly) so it depens on the environment you're working in. Suggestion # 1 is a valid point but inpractical in my case 700-900 stored procedures and
#5 I'm working on! :) Thanks for the help.

!Bastard
Jul 22 '05 #7

P: n/a
>A little goes a long way when dealing with SQL Injection and Cross Site Scripting (which doesnt seem to get too many people concerned for some reason).

Cross-site scripting defenses are usually somewhat trivial to defeat.
It's tough to do more then check the referrer, but that's not too hard
to spoof. Storing critical variables server-side and using sessions
can reduce many of the benefits of cross-site scripting too.
Yes, while validation is not fool proof, very
few things are in this world are, but at the same time the benefits of doing it over not doing it are considerable.
The primary purpose of input validation is data integrity, not
security. That's not to say it isn't of use in helping secure an app,
but it can't be the only thing you do to provude for a secure
environment.

That said, validation should always take place on both the client and
the server. Some validation techniques work better in one place or
the other, but heading off user input errors at the client is far more
efficient than using the server.

Jeff
On Thu, 17 Feb 2005 06:52:16 -0500, "Bob Barrows [MVP]" <re******@NOyahoo.SPAMcom> wrote:
BTR wrote:
I have been working on this particular project for a little over 2
weeks now. This product contains between 700-900 stored procedures to
handle just about all you can imagine within the product. I just
personally rewrote/reformatted close to 150 of them myself. Nothing
too fancy, mostly a lot of formatting. We have a little down time
between Q/A and fixing any bugs they find so I decided to test the
security of the site with Cross-Site Scripting and SQL injection.


If you pass arguments via the Parameters collection of the Command object,
or using the procedure-as-connection-method technique
(http://tinyurl.com/jyy0), and you do not use the parameters to build
dynamic sql statements inside your stored procedures, then you are
invulnerable to sql injection. Period. SQL Injection depends on the use of
dynamic sql. Without dynamic SQL, there can be no SQL Injection. More:

http://mvp.unixwiz.net/techtips/sql-injection.html
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=23
http://www.nextgenss.com/papers/adva..._injection.pdf
http://www.nextgenss.com/papers/more..._injection.pdf
Validation techniques can be defeated, although the time it takes a hacker
to defeat them may cause him to move on to a more vulnerable site. So:
always validate in server-side code to avoid CSS exploits. Client-side
validation should supplement the server-side validation, not replace it. The
only reason to use client-side validation is to provide a better user
experience, allowing data entry errors to be causght immediately rather than
after submission.

Bob Barrows


Jul 22 '05 #8

P: n/a
BTR wrote:
SQL Injection is most easily defeated using regular
expressions to validate all of your data.
Not really. I can use ADODB.Command and NEVER validate any data, and
still be 100% protected from SQL injection.

You have to realize that alot of the poeple here are not SQL experts.
Most everyone learned SQL by creating these dynamically built SQL
strings including myself. I've just recently started working with
SP's.


My comments directly rebut your "most easily defeated" assertion, and do not
attempt to disparage data validation.

As a side note, exact preservation of the original input data is
occasionally not only preferable, but *required* (regulatory or liability
reasons, for example). The requirement to preserve the original, in effect,
forbids validation. So how are you going to protect yourself from SQL
injection if validation is off the table?
RegularExpressions are a great defense against SQL injection
and a great way to validate data before it goes into the dB. Just
because you validate your data in the SQL (if you even do that) just
means you have to write more SQL and depending on what you're doing
with it could slow things down.
Again, I never said not to validate data before sending it to the database.
I just don't think regular expressions should be your last line of defense.
The #1 call tech support gets is What is my password? It is generally
thought that to keeps costs and the amount of phone calls down,
limiting the characters allowed in the PW field to numbers and
characters was the user friendly way to handle it.
This "hacker's wet dream" horrifies me on so many levels. Passwords are
inconvenient, so let's not make 'em too tough to remember.
Easily defeated: http://livehttpheaders.mozdev.org/

So I suppose, you would just rather not do it?


Yes. I would not do it. I would rather assume the user can change *ANYTHING*
in the request.
I think its wrong to say Dont do something because
its easily defeated or takes a special tool to do so.
1. I do not consider Firefox extensions "special tools" as much as browser
features, many of which will find their way into all manner of future
browsers.

2. I think the use of HTTP_REFERER for security is a bad practice because it
lends a false sense of security despite having no reliability whatsoever. I
can absolutely think of good uses for it, but they *enhance* or *supplement*
the user's experience rather than impede it.
Not all developers are dB admins. In fact is most case I've been
involved with, the dB servers are run by other people, some smart
(will limit who can run what SP, preventing escalation) and others
are not (in one case cant even set up a FTP server properly) so it
depens on the environment you're working in. Suggestion # 1 is a
valid point but inpractical in my case 700-900 stored procedures and
#5 I'm working on!


If the developer is not a DBA, then someone else certainly is. And I
guarantee that DBA would like nothing better than removing SELECT, INSERT
and UPDATE from the web application's login -- and almost certainly would
prefer to be an essential part of the change management/migration process.

And FWIW, db_securityadmin is sufficient in SQL Server for the developer to
manage SP permissions. DBA is overkill.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Jul 22 '05 #9

P: n/a
BTR
Its obvious Dave Anderson and I disagree on some things but thats OK. It's what, makes this kind of forum the way it is. After some considerable testing today on the nature of Stored Procedures and
applying an Injection attack, I've exposed an exploit that isn't from a buffer overflow or a security hole in the SQL Server application itself but more along the lines of taking advantage of SQL and
stored procs. The exploit deals with permission settings on the SP's themselves. Now if you've been paying attention to this thread at all, you'll notice that Dave limits the permissions on the SP's
and I'm sure that some other DBA's follow suit. However, I am also sure that there is a large portion of the world that doesn't, as you may have noticed the spread of the Slammer virus using 'sa'
password to propagate itself. Whether it be laziness, incompetence or what ever, I'm sure there are literally thousands of server running millions of SP's without any regard to permissions. With that
in mind this makes anything you try a pretty likely event it will succeed. But also bear in mind that certain things also need to be in place, like the site has to be vulnerable to CSS attacks etc
etc.

I wont go into details but will more or less outline the beginning of what I think is a proof of concept. Granted my knowledge of SP's is pretty limited so bear with me:

The proof of concept is as follows.

I CSS the site exposing the name of a SP dealing with login information.
get_user_login_info

So, this particular SP will accept VARCHAR for username and password.

Step 1:
I've created a dynamic SQL statement that will create a Stored Procedure with the same name of the one that was exposed.

SET @var = 'CREATE STORED PROCEDURE.....'
SET @vat + @var = 'SELECT * FROM INFORMATION_SCHEMA.TABLES'
etc etc...

Step 2: I've created a Delete SP statement that I will Inject into the SQL
EXEC get_user_login_info 'delete procedure [dbo].[get_user_login_info]'

Step 3:
I fire the EXEC statement at itself telling to delete itself. (This actually happened today while testing.)
You can tell a SP to delete itself. Where the exploit per say comes into play.
This could easily be defeated by restricting permissions on the SP, but bear in mind that my guess is most people wouldn't do that for any number of reasons making it pretty readily available.

Step 4:
Continuing with the delete statement, you Execure the dynamic query that you made earlier, after you delete the original stored Procedure.

Because the web page is always calling the SP, you essentially deleted the original SP, and created one of your own, with your own variables, and would be able to access the SCHEMA tables or anything
else for that matter via your dynamic SQL statement. The combination of deleting and re-writing the SP would allow you access to anything in the database. Again, all of your ducks would have to be in
a row with permissions etc but again this is more of a proof of concept anyhow.
Any feedback?
~Bastard

On Thu, 17 Feb 2005 16:56:19 -0600, "Dave Anderson" <GT**********@spammotel.com> wrote:
BTR wrote:
SQL Injection is most easily defeated using regular
expressions to validate all of your data.

Not really. I can use ADODB.Command and NEVER validate any data, and
still be 100% protected from SQL injection.

You have to realize that alot of the poeple here are not SQL experts.
Most everyone learned SQL by creating these dynamically built SQL
strings including myself. I've just recently started working with
SP's.


My comments directly rebut your "most easily defeated" assertion, and do not
attempt to disparage data validation.

As a side note, exact preservation of the original input data is
occasionally not only preferable, but *required* (regulatory or liability
reasons, for example). The requirement to preserve the original, in effect,
forbids validation. So how are you going to protect yourself from SQL
injection if validation is off the table?
RegularExpressions are a great defense against SQL injection
and a great way to validate data before it goes into the dB. Just
because you validate your data in the SQL (if you even do that) just
means you have to write more SQL and depending on what you're doing
with it could slow things down.


Again, I never said not to validate data before sending it to the database.
I just don't think regular expressions should be your last line of defense.
The #1 call tech support gets is What is my password? It is generally
thought that to keeps costs and the amount of phone calls down,
limiting the characters allowed in the PW field to numbers and
characters was the user friendly way to handle it.


This "hacker's wet dream" horrifies me on so many levels. Passwords are
inconvenient, so let's not make 'em too tough to remember.
Easily defeated: http://livehttpheaders.mozdev.org/

So I suppose, you would just rather not do it?


Yes. I would not do it. I would rather assume the user can change *ANYTHING*
in the request.
I think its wrong to say Dont do something because
its easily defeated or takes a special tool to do so.


1. I do not consider Firefox extensions "special tools" as much as browser
features, many of which will find their way into all manner of future
browsers.

2. I think the use of HTTP_REFERER for security is a bad practice because it
lends a false sense of security despite having no reliability whatsoever. I
can absolutely think of good uses for it, but they *enhance* or *supplement*
the user's experience rather than impede it.
Not all developers are dB admins. In fact is most case I've been
involved with, the dB servers are run by other people, some smart
(will limit who can run what SP, preventing escalation) and others
are not (in one case cant even set up a FTP server properly) so it
depens on the environment you're working in. Suggestion # 1 is a
valid point but inpractical in my case 700-900 stored procedures and
#5 I'm working on!


If the developer is not a DBA, then someone else certainly is. And I
guarantee that DBA would like nothing better than removing SELECT, INSERT
and UPDATE from the web application's login -- and almost certainly would
prefer to be an essential part of the change management/migration process.

And FWIW, db_securityadmin is sufficient in SQL Server for the developer to
manage SP permissions. DBA is overkill.


Jul 22 '05 #10

P: n/a
Roland Hall wrote:
At that resolution you might be able to decrease your font and get it
all on a single line. Better yet, double your font size, grab your
wireless keyboard and mouse and sit across the room so you're far
enough to read it.


Heh. I was using the [Web Developer] Firefox extension a couple of days ago
to tweak styles on one of the pages I was viewing. In particular, I was
changing the font-size attribute for SELECT elements, and I noticed that
Firefox resizes as-you-type, so each keystroke changes the rendering of the
document. In short, I discovered that Firefox really will render fonts all
the way down to 1pt. The effect on the select element is stunning, since
*everything* shrinks with it (scrollbar, etc.).

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Jul 22 '05 #11

P: n/a
"Dave Anderson" wrote in message
news:e%****************@TK2MSFTNGP10.phx.gbl...
: Roland Hall wrote:
: > At that resolution you might be able to decrease your font and get it
: > all on a single line. Better yet, double your font size, grab your
: > wireless keyboard and mouse and sit across the room so you're far
: > enough to read it.
:
: Heh. I was using the [Web Developer] Firefox extension a couple of days
ago
: to tweak styles on one of the pages I was viewing. In particular, I was
: changing the font-size attribute for SELECT elements, and I noticed that
: Firefox resizes as-you-type, so each keystroke changes the rendering of
the
: document. In short, I discovered that Firefox really will render fonts all
: the way down to 1pt. The effect on the select element is stunning, since
: *everything* shrinks with it (scrollbar, etc.).

That sounds interesting. I'll have to check that out. It may be a cheaper
alternative to drinking.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp
Jul 22 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.