Dan Gardner oversees all technology development including software development, quality assurance, and system integration. He assumed this position in February 2008. Previously, Dan was Chief Technology Officer at Renew Data Corp., as well as one of the original founders. Renew is a leader provider of e-discovery and electronically stored information risk management services. Renew went from startup to a $30M-plus company in less than five years and has made the Inc. 500 list twice. Dan has also held software development positions at TranScape (a Pitney Bowes company) and Ontrack Data International. Dan holds a bachelor’s degree in Mathematics from St. John’s University, and a master’s degree in Mathematics from the University of Notre Dame.
More by Dan Gardner
WP_Query Object
(
[query] => Array
(
[post_type] => Array
(
[0] => post
[1] => webinars
)
[posts_per_page] => -1
[post_status] => publish
[meta_query] => Array
(
[relation] => OR
[0] => Array
(
[key] => new_authors
[value] => "5"
[compare] => LIKE
)
[1] => Array
(
[key] => new_presenters
[value] => "5"
[compare] => LIKE
)
)
)
[query_vars] => Array
(
[post_type] => Array
(
[0] => post
[1] => webinars
)
[posts_per_page] => -1
[post_status] => publish
[meta_query] => Array
(
[relation] => OR
[0] => Array
(
[key] => new_authors
[value] => "5"
[compare] => LIKE
)
[1] => Array
(
[key] => new_presenters
[value] => "5"
[compare] => LIKE
)
)
[error] =>
[m] =>
[p] => 0
[post_parent] =>
[subpost] =>
[subpost_id] =>
[attachment] =>
[attachment_id] => 0
[name] =>
[pagename] =>
[page_id] => 0
[second] =>
[minute] =>
[hour] =>
[day] => 0
[monthnum] => 0
[year] => 0
[w] => 0
[category_name] =>
[tag] =>
[cat] =>
[tag_id] =>
[author] =>
[author_name] =>
[feed] =>
[tb] =>
[paged] => 0
[meta_key] =>
[meta_value] =>
[preview] =>
[s] =>
[sentence] =>
[title] =>
[fields] =>
[menu_order] =>
[embed] =>
[category__in] => Array
(
)
[category__not_in] => Array
(
)
[category__and] => Array
(
)
[post__in] => Array
(
)
[post__not_in] => Array
(
)
[post_name__in] => Array
(
)
[tag__in] => Array
(
)
[tag__not_in] => Array
(
)
[tag__and] => Array
(
)
[tag_slug__in] => Array
(
)
[tag_slug__and] => Array
(
)
[post_parent__in] => Array
(
)
[post_parent__not_in] => Array
(
)
[author__in] => Array
(
)
[author__not_in] => Array
(
)
[search_columns] => Array
(
)
[ignore_sticky_posts] =>
[suppress_filters] =>
[cache_results] => 1
[update_post_term_cache] => 1
[update_menu_item_cache] =>
[lazy_load_term_meta] => 1
[update_post_meta_cache] => 1
[nopaging] => 1
[comments_per_page] => 50
[no_found_rows] =>
[order] => DESC
)
[tax_query] => WP_Tax_Query Object
(
[queries] => Array
(
)
[relation] => AND
[table_aliases:protected] => Array
(
)
[queried_terms] => Array
(
)
[primary_table] => wp_posts
[primary_id_column] => ID
)
[meta_query] => WP_Meta_Query Object
(
[queries] => Array
(
[0] => Array
(
[key] => new_authors
[value] => "5"
[compare] => LIKE
)
[1] => Array
(
[key] => new_presenters
[value] => "5"
[compare] => LIKE
)
[relation] => OR
)
[relation] => OR
[meta_table] => wp_postmeta
[meta_id_column] => post_id
[primary_table] => wp_posts
[primary_id_column] => ID
[table_aliases:protected] => Array
(
[0] => wp_postmeta
)
[clauses:protected] => Array
(
[wp_postmeta] => Array
(
[key] => new_authors
[value] => "5"
[compare] => LIKE
[compare_key] => =
[alias] => wp_postmeta
[cast] => CHAR
)
[wp_postmeta-1] => Array
(
[key] => new_presenters
[value] => "5"
[compare] => LIKE
[compare_key] => =
[alias] => wp_postmeta
[cast] => CHAR
)
)
[has_or_relation:protected] => 1
)
[date_query] =>
[request] => SELECT wp_posts.ID
FROM wp_posts INNER JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id )
WHERE 1=1 AND (
( wp_postmeta.meta_key = 'new_authors' AND wp_postmeta.meta_value LIKE '{7afa1622d5c120eb6a5d73534a9a90630ca80d28b9c520cd99cbff89720e6baf}\"5\"{7afa1622d5c120eb6a5d73534a9a90630ca80d28b9c520cd99cbff89720e6baf}' )
OR
( wp_postmeta.meta_key = 'new_presenters' AND wp_postmeta.meta_value LIKE '{7afa1622d5c120eb6a5d73534a9a90630ca80d28b9c520cd99cbff89720e6baf}\"5\"{7afa1622d5c120eb6a5d73534a9a90630ca80d28b9c520cd99cbff89720e6baf}' )
) AND wp_posts.post_type IN ('post', 'webinars') AND ((wp_posts.post_status = 'publish'))
GROUP BY wp_posts.ID
ORDER BY wp_posts.post_date DESC
[posts] => Array
(
[0] => WP_Post Object
(
[ID] => 1149
[post_author] => 5
[post_date] => 2013-08-29 07:00:37
[post_date_gmt] => 2013-08-29 07:00:37
[post_content] => I recently read an editorial on SQL Server Central by Steve Jones titled “Review Your Code” in which he asserts: “if you write code after today that's susceptible to SQL Injection, you ought to be fired”.
I am certainly not going to disagree. However, I don’t believe we should narrow the scope of the witch hunt to just the “coders”. If you want to go on a termination rampage after a breach, you should probably look beyond just the code monkeys.
What about anyone who calls themselves an “architect”. If you design a Swiss cheese system to begin with, what do you expect from the engineers?
What about the DBAs? Why aren’t they standing up and demanding the use of parameterized queries to interact with their databases? Or better yet, demand applications interact with the database using only stored procedures so that the application user(s) only need(s) CONNECT and EXECUTE permissions?
What about QA? How does an application get deployed these days without at least some cursory security testing?
If the application is business critical, what about the decision makers? Are they willing to write the checks to perform a REAL penetration test on the application? (Not just a scan)
This list is by no means exhaustive. Depending upon your organization, there are probably plenty of other roles on the development team that should be security conscious too. So when it comes time to hand out punishment after a breach, just firing the code monkey will probably not fix your problem.
[post_title] => Is SQL Injection a Terminable Offense?
[post_excerpt] =>
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => blog-technical-vulnerability-management-is-sql-injection-a-terminable-offense
[to_ping] =>
[pinged] =>
[post_modified] => 2021-04-13 00:06:01
[post_modified_gmt] => 2021-04-13 00:06:01
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://netspiblogdev.wpengine.com/?p=1149
[menu_order] => 743
[post_type] => post
[post_mime_type] =>
[comment_count] => 1
[filter] => raw
)
[1] => WP_Post Object
(
[ID] => 1299
[post_author] => 5
[post_date] => 2009-11-06 07:00:40
[post_date_gmt] => 2009-11-06 07:00:40
[post_content] =>
In system development a "backdoor" creates a way of bypassing normal authentication to allow access to a system.Secret backdoor credentials often exist deep in the thousands or millions of lines of code that make up a system. This is just one reason why building your own user management/authorization/authentication schemes into systems is a bad idea, but that is a topic for another time.
I was recently on an elevator with some people who apparently worked for a software company. I overheard something about how their support people use a backdoor in order to access the application. I thought that the practice of installing backdoors in applications was well known to be a very bad idea, and that the practice went the way of the NeXT machine. Perhaps I was wrong.
This bit of overheard conversation opens a Pandora's box of questions:Which applications have backdoors? Should my software vendor be required to tell me if the application has a backdoor? How many applications are out there that we don't know about with backdoors that were created by developers, either well intentioned or malicious?
Imagine if a popular home finance package, for example, had a backdoor. Even if it had been put there with the best of intentions, all it would take is one malicious individual with knowledge of the backdoor to destroy not only the software vendor but also the personal finances of millions of individuals.
NetSPI's application code review assessments include checking for backdoors. Given the small amount of application code that ever gets reviewed, let alone by a third-party security assessment like NetSPI's, it is safe to assume that there are a lot of scary things buried in trillions of lines of source code out there.
My advice:
Developers:Don't implement backdoors. It is a very bad practice.
QA& Development managers:Include checks for backdoors in your SDLC.
Consumers:Ask your application vendors if there are any backdoors in their products, and get their answers in writing.
SQL injection vulnerabilities are common out in the real world. We spend a lot of time and effort looking for SQL injection vulnerabilities in application code, a good and necessary practice. Application security, however, must be considered at every layer of the system. In fact, by using a good database and data access layer design, we can help eliminate the possibility of a SQL injection vulnerability.
True, the topic of database and data access layer design is expansive, including the use of service accounts and row-level authorization.But for now, here's a simple way using two small requirements to make sure that the database itself is doing its part to facilitate a secure database and data access layer and to protect against SQL injection attacks.
These two requirements are:
1)All data access should occur via parameterized stored procedures.
2) Users should be limited to CONNECT and EXECUTE privileges.
By ensuring that all data access is via stored procedures, we can enforce the practice of parameterizing variables, thus eliminating the possibility of random SQL statements getting to our database. Of course, you must also make sure that your stored procedures are properly written and do not include any insecure practices such as using sp_executesql.
By limiting users to CONNECT and EXECUTE privileges, we can limit the possibility of users executing random SQL statements. If they try to SELECT anything, for example, it will fail.
[post_title] => Preventing SQL Injection at the Database
[post_excerpt] =>
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => preventing-sql-injection-at-the-database
[to_ping] =>
[pinged] =>
[post_modified] => 2021-04-13 00:06:27
[post_modified_gmt] => 2021-04-13 00:06:27
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://netspiblogdev.wpengine.com/?p=1309
[menu_order] => 902
[post_type] => post
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
)
[post_count] => 3
[current_post] => -1
[before_loop] => 1
[in_the_loop] =>
[post] => WP_Post Object
(
[ID] => 1149
[post_author] => 5
[post_date] => 2013-08-29 07:00:37
[post_date_gmt] => 2013-08-29 07:00:37
[post_content] => I recently read an editorial on SQL Server Central by Steve Jones titled “Review Your Code” in which he asserts: “if you write code after today that's susceptible to SQL Injection, you ought to be fired”.
I am certainly not going to disagree. However, I don’t believe we should narrow the scope of the witch hunt to just the “coders”. If you want to go on a termination rampage after a breach, you should probably look beyond just the code monkeys.
What about anyone who calls themselves an “architect”. If you design a Swiss cheese system to begin with, what do you expect from the engineers?
What about the DBAs? Why aren’t they standing up and demanding the use of parameterized queries to interact with their databases? Or better yet, demand applications interact with the database using only stored procedures so that the application user(s) only need(s) CONNECT and EXECUTE permissions?
What about QA? How does an application get deployed these days without at least some cursory security testing?
If the application is business critical, what about the decision makers? Are they willing to write the checks to perform a REAL penetration test on the application? (Not just a scan)
This list is by no means exhaustive. Depending upon your organization, there are probably plenty of other roles on the development team that should be security conscious too. So when it comes time to hand out punishment after a breach, just firing the code monkey will probably not fix your problem.
[post_title] => Is SQL Injection a Terminable Offense?
[post_excerpt] =>
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => blog-technical-vulnerability-management-is-sql-injection-a-terminable-offense
[to_ping] =>
[pinged] =>
[post_modified] => 2021-04-13 00:06:01
[post_modified_gmt] => 2021-04-13 00:06:01
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://netspiblogdev.wpengine.com/?p=1149
[menu_order] => 743
[post_type] => post
[post_mime_type] =>
[comment_count] => 1
[filter] => raw
)
[comment_count] => 0
[current_comment] => -1
[found_posts] => 3
[max_num_pages] => 0
[max_num_comment_pages] => 0
[is_single] =>
[is_preview] =>
[is_page] =>
[is_archive] =>
[is_date] =>
[is_year] =>
[is_month] =>
[is_day] =>
[is_time] =>
[is_author] =>
[is_category] =>
[is_tag] =>
[is_tax] =>
[is_search] =>
[is_feed] =>
[is_comment_feed] =>
[is_trackback] =>
[is_home] => 1
[is_privacy_policy] =>
[is_404] =>
[is_embed] =>
[is_paged] =>
[is_admin] =>
[is_attachment] =>
[is_singular] =>
[is_robots] =>
[is_favicon] =>
[is_posts_page] =>
[is_post_type_archive] =>
[query_vars_hash:WP_Query:private] => 3cebc23cb191b42e026ef2f806a0edca
[query_vars_changed:WP_Query:private] =>
[thumbnails_cached] =>
[allow_query_attachment_by_filename:protected] =>
[stopwords:WP_Query:private] =>
[compat_fields:WP_Query:private] => Array
(
[0] => query_vars_hash
[1] => query_vars_changed
)
[compat_methods:WP_Query:private] => Array
(
[0] => init_query_flags
[1] => parse_tax_query
)
)
Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.
Name
Domain
Purpose
Expiry
Type
YSC
youtube.com
YouTube session cookie.
52 years
HTTP
Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Name
Domain
Purpose
Expiry
Type
VISITOR_INFO1_LIVE
youtube.com
YouTube cookie.
6 months
HTTP
Test
test.com
Testing
7 days
HTTP
Analytics cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
We do not use cookies of this type.
Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
We do not use cookies of this type.
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
We do not use cookies of this type.
Cookies are small text files that can be used by websites to make a user's experience more efficient. The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.
Cookie Settings
Discover how the NetSPI BAS solution helps organizations validate the efficacy of existing security controls and understand their Security Posture and Readiness.
