Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
Article Discussions
»
Article Discussions by Author
»
Discuss Content Posted by Brian Kelley
»
Stored Procedures and SQL Injection
19 posts, Page 2 of 2
««
1
2
Stored Procedures and SQL Injection
Rate Topic
Display Mode
Topic Options
Author
Message
davoscollective
davoscollective
Posted Monday, February 18, 2013 3:56 PM
SSC-Addicted
Group: General Forum Members
Last Login: Today @ 8:01 PM
Points: 408,
Visits: 688
And this one:
Post Attachments
untitled.png
(
147 views,
376.16 KB
)
Post #1421362
Geoff A
Geoff A
Posted Tuesday, February 19, 2013 8:30 AM
SSC-Addicted
Group: General Forum Members
Last Login: Monday, May 20, 2013 7:10 AM
Points: 485,
Visits: 1,568
Thanks Brian. This article is extremely informative. I hate permissions in SQL but your approach is spot on for making it understandable.
Post #1421676
Dave Vroman
Dave Vroman
Posted Tuesday, February 19, 2013 10:31 AM
SSC Rookie
Group: General Forum Members
Last Login: Yesterday @ 11:17 AM
Points: 46,
Visits: 206
Using stored procedures is a requirement for PCI compliance. It is one of the requirements that slows down or stops all manner of nasties (well delineated in earlier posts). If your web site accepts credit cards, this is one of the many requirements.
Post #1421756
Michael Valentine Jones
Michael Valentine Jones
Posted Tuesday, February 19, 2013 10:48 AM
SSCrazy
Group: General Forum Members
Last Login: Today @ 6:26 PM
Points: 2,945,
Visits: 10,514
Dave Vroman (2/19/2013)
Using stored procedures is a requirement for PCI compliance. It is one of the requirements that slows down or stops all manner of nasties (well delineated in earlier posts). If your web site accepts credit cards, this is one of the many requirements.
I recently went through the Payment Card Industry (PCI) Data Security Standard V2.0 documents in detail and never saw anything that stated that you are required to use stored procedures.
Can you point to a specific PCI standards document that states this requirement?
Post #1421766
Dave Vroman
Dave Vroman
Posted Tuesday, February 19, 2013 10:58 AM
SSC Rookie
Group: General Forum Members
Last Login: Yesterday @ 11:17 AM
Points: 46,
Visits: 206
It totally depends on the level of PCI compliance. I don't remember where it was and I am no longer at that company. It was not specifically spelled out in the compliance papers, but it was required by the company that was testing for compliance.
Post #1421773
Lynn Pettis
Lynn Pettis
Posted Tuesday, February 19, 2013 12:26 PM
SSC-Insane
Group: General Forum Members
Last Login: Today @ 7:50 PM
Points: 21,624,
Visits: 27,465
Sounds like an auditing firm making a determination not specified in the standard because they think it best. If it isn't in the actual standard how can the justify failing you if you aren't using stored procedures?
Lynn Pettis
For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here
or
when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here
and
here
Managing Transaction Logs
SQL Musings from the Desert
Fountain Valley SQL
(My Mirror Blog)
Post #1421804
K. Brian Kelley
K. Brian Kelley
Posted Tuesday, February 19, 2013 1:47 PM
Keeper of the Duck
Group: Moderators
Last Login: Yesterday @ 1:55 PM
Points: 6,584,
Visits: 1,789
Remember that auditing firms make an attestation as to whether you're in compliance. That attestation is basically a statement of confidence. So, yes, it's entirely possible one firm would require something when another wouldn't if the requirement is not explicitly spelled out in the standard. For instance, way back in the day, this is how one firm we did business with got a SAS70 attestation even though they didn't patch their Windows servers. I wish I was kidding. Our auditors, on the other hand, required a detailed patch management plan along with verification that the controls were being met before they signed off each time for our SAS70 attestation. Why the difference? SAS70 was very vague and didn't have anything specific with regards to those sorts of controls.
K. Brian Kelley, CISA, MCSE, Security+, MVP - SQL Server
Regular Columnist (Security), SQLServerCentral.com
Author of
Introduction to SQL Server: Basic Skills for Any SQL Server User
|
Professional Development blog
|
Technical Blog
|
LinkedIn
|
Twitter
Post #1421836
Michael Valentine Jones
Michael Valentine Jones
Posted Tuesday, February 19, 2013 9:35 PM
SSCrazy
Group: General Forum Members
Last Login: Today @ 6:26 PM
Points: 2,945,
Visits: 10,514
Dave Vroman (2/19/2013)
It totally depends on the level of PCI compliance. I don't remember where it was and I am no longer at that company. It was not specifically spelled out in the compliance papers, but it was required by the company that was testing for compliance.
Sounds like the auditor was just making stuff up.
Not that I think using stored procedures is a bad thing, but this sort of thing is why I have very little respect for firms that do PCI, SAS70, SOX, etc. audits.
My experience is that they zoom in on petty items while they ignore or don't even understand serious problems.
Post #1421923
David.Poole
David.Poole
Posted Thursday, February 21, 2013 3:54 PM
SSCrazy
Group: General Forum Members
Last Login: 2 days ago @ 9:35 AM
Points: 2,749,
Visits: 1,407
Have a good read of https://www.owasp.org/index.php/Main_Page
LinkedIn Profile
Post #1422821
« Prev Topic
|
Next Topic »
19 posts, Page 2 of 2
««
1
2
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.