Mixing
How to fix Sonar “SQL queries should not be vulnerable to injection attacks” on C#
0
Sonar rule link: https://rules.sonarsource.com/csharp/RSPEC-3649
I have a sql string that takes DB name as parameter. It's like:
UPDATE [@DBNAME].[dbo].[MyTable] SET [Column]='1'
Sonar doesn't accept this string but I can't give DB name as SqlCommand parameter.
Does anyone has an idea to fix this?
I am looking for a solution other than suppress or turning off Sonar Analysis.
ps: I use SqlServer 2012.
c#
sql-server sonarqube software-quality asked Nov 20 '18 at 12:28
sosasosa
217
|
show 5 more comments
0
Sonar rule link: https://rules.sonarsource.com/csharp/RSPEC-3649
I have a sql string that takes DB name as parameter. It's like:
UPDATE [@DBNAME].[dbo].[MyTable] SET [Column]='1'
Sonar doesn't accept this string but I can't give DB name as SqlCommand parameter.
Does anyone has an idea to fix this?
I am looking for a solution other than suppress or turning off Sonar Analysis.
ps: I use SqlServer 2012.
c#
sql-server sonarqube software-quality asked Nov 20 '18 at 12:28
sosasosa
217
Possible duplicate of Turning Sonar off for certain code
– BWA
Nov 20 '18 at 12:31
2
Either suppress the warning (this is a legitimate use case for string replacement) or change the approach to useSqlConnection.ChangeDatabasebefore issuing theUPDATE(or a newSqlConnectionwith a correctInitial Data Source).
– Jeroen Mostert
Nov 20 '18 at 12:32
@JeroenMostert in this case when you control string in 100% I think string replacement is ok. But generally you have right.
– BWA
Nov 20 '18 at 12:37
All such tools have a chance of flagging something as wrong where you know more about the situation. As long as you have made sure that the database name isn't something the user can type in directly and that is from a verified and secure source, then you should tell Sonar to ignore this particular statement.
– Lasse Vågsæther Karlsen
Nov 20 '18 at 12:39
2
Suppressing is a solution. These tools are not all-knowing. From your question, I can't know if the string is indeed properly vetted by the application, and neither can Sonar, hence the warning. If you, the developer, know this string is fine, then you have to suppress, because the database name is not parameterizable in T-SQL. Removing it from the statement means rewriting code.
– Jeroen Mostert
Nov 20 '18 at 12:41
|
show 5 more comments
0
0
0
Sonar rule link: https://rules.sonarsource.com/csharp/RSPEC-3649
I have a sql string that takes DB name as parameter. It's like:
UPDATE [@DBNAME].[dbo].[MyTable] SET [Column]='1'
Sonar doesn't accept this string but I can't give DB name as SqlCommand parameter.
Does anyone has an idea to fix this?
I am looking for a solution other than suppress or turning off Sonar Analysis.
ps: I use SqlServer 2012.
c#
sql-server sonarqube software-quality asked Nov 20 '18 at 12:28
sosasosa
217
Sonar rule link: https://rules.sonarsource.com/csharp/RSPEC-3649
I have a sql string that takes DB name as parameter. It's like:
UPDATE [@DBNAME].[dbo].[MyTable] SET [Column]='1'
Sonar doesn't accept this string but I can't give DB name as SqlCommand parameter.
Does anyone has an idea to fix this?
I am looking for a solution other than suppress or turning off Sonar Analysis.
ps: I use SqlServer 2012.
c#
sql-server sonarqube software-quality c#
sql-server sonarqube software-quality asked Nov 20 '18 at 12:28
sosasosa
217
asked Nov 20 '18 at 12:28
sosasosa
217
edited Nov 20 '18 at 13:41
sosa
asked Nov 20 '18 at 12:28
sosasosa
217
asked Nov 20 '18 at 12:28
sosasosa
217
asked Nov 20 '18 at 12:28
sosasosa
217
217
Possible duplicate of Turning Sonar off for certain code
– BWA
Nov 20 '18 at 12:31
2
Either suppress the warning (this is a legitimate use case for string replacement) or change the approach to useSqlConnection.ChangeDatabasebefore issuing theUPDATE(or a newSqlConnectionwith a correctInitial Data Source).
– Jeroen Mostert
Nov 20 '18 at 12:32
@JeroenMostert in this case when you control string in 100% I think string replacement is ok. But generally you have right.
– BWA
Nov 20 '18 at 12:37
All such tools have a chance of flagging something as wrong where you know more about the situation. As long as you have made sure that the database name isn't something the user can type in directly and that is from a verified and secure source, then you should tell Sonar to ignore this particular statement.
– Lasse Vågsæther Karlsen
Nov 20 '18 at 12:39
2
Suppressing is a solution. These tools are not all-knowing. From your question, I can't know if the string is indeed properly vetted by the application, and neither can Sonar, hence the warning. If you, the developer, know this string is fine, then you have to suppress, because the database name is not parameterizable in T-SQL. Removing it from the statement means rewriting code.
– Jeroen Mostert
Nov 20 '18 at 12:41
|
show 5 more comments
Possible duplicate of Turning Sonar off for certain code
– BWA
Nov 20 '18 at 12:31
2
Either suppress the warning (this is a legitimate use case for string replacement) or change the approach to useSqlConnection.ChangeDatabasebefore issuing theUPDATE(or a newSqlConnectionwith a correctInitial Data Source).
– Jeroen Mostert
Nov 20 '18 at 12:32
@JeroenMostert in this case when you control string in 100% I think string replacement is ok. But generally you have right.
– BWA
Nov 20 '18 at 12:37
All such tools have a chance of flagging something as wrong where you know more about the situation. As long as you have made sure that the database name isn't something the user can type in directly and that is from a verified and secure source, then you should tell Sonar to ignore this particular statement.
– Lasse Vågsæther Karlsen
Nov 20 '18 at 12:39
2
Suppressing is a solution. These tools are not all-knowing. From your question, I can't know if the string is indeed properly vetted by the application, and neither can Sonar, hence the warning. If you, the developer, know this string is fine, then you have to suppress, because the database name is not parameterizable in T-SQL. Removing it from the statement means rewriting code.
– Jeroen Mostert
Nov 20 '18 at 12:41
Possible duplicate of Turning Sonar off for certain code
– BWA
Nov 20 '18 at 12:31
Possible duplicate of Turning Sonar off for certain code
– BWA
Nov 20 '18 at 12:31
2
2
Either suppress the warning (this is a legitimate use case for string replacement) or change the approach to use
SqlConnection.ChangeDatabase before issuing the UPDATE (or a new SqlConnection with a correct Initial Data Source).– Jeroen Mostert
Nov 20 '18 at 12:32
Either suppress the warning (this is a legitimate use case for string replacement) or change the approach to use
SqlConnection.ChangeDatabase before issuing the UPDATE (or a new SqlConnection with a correct Initial Data Source).– Jeroen Mostert
Nov 20 '18 at 12:32
@JeroenMostert in this case when you control string in 100% I think string replacement is ok. But generally you have right.
– BWA
Nov 20 '18 at 12:37
@JeroenMostert in this case when you control string in 100% I think string replacement is ok. But generally you have right.
– BWA
Nov 20 '18 at 12:37
All such tools have a chance of flagging something as wrong where you know more about the situation. As long as you have made sure that the database name isn't something the user can type in directly and that is from a verified and secure source, then you should tell Sonar to ignore this particular statement.
– Lasse Vågsæther Karlsen
Nov 20 '18 at 12:39
All such tools have a chance of flagging something as wrong where you know more about the situation. As long as you have made sure that the database name isn't something the user can type in directly and that is from a verified and secure source, then you should tell Sonar to ignore this particular statement.
– Lasse Vågsæther Karlsen
Nov 20 '18 at 12:39
2
2
Suppressing is a solution. These tools are not all-knowing. From your question, I can't know if the string is indeed properly vetted by the application, and neither can Sonar, hence the warning. If you, the developer, know this string is fine, then you have to suppress, because the database name is not parameterizable in T-SQL. Removing it from the statement means rewriting code.
– Jeroen Mostert
Nov 20 '18 at 12:41
Suppressing is a solution. These tools are not all-knowing. From your question, I can't know if the string is indeed properly vetted by the application, and neither can Sonar, hence the warning. If you, the developer, know this string is fine, then you have to suppress, because the database name is not parameterizable in T-SQL. Removing it from the statement means rewriting code.
– Jeroen Mostert
Nov 20 '18 at 12:41
|
show 5 more comments
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53393009%2fhow-to-fix-sonar-sql-queries-should-not-be-vulnerable-to-injection-attacks-on%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
draft saved
draft discarded
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53393009%2fhow-to-fix-sonar-sql-queries-should-not-be-vulnerable-to-injection-attacks-on%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Possible duplicate of Turning Sonar off for certain code
– BWA
Nov 20 '18 at 12:31
2
Either suppress the warning (this is a legitimate use case for string replacement) or change the approach to use
SqlConnection.ChangeDatabasebefore issuing theUPDATE(or a newSqlConnectionwith a correctInitial Data Source).– Jeroen Mostert
Nov 20 '18 at 12:32
@JeroenMostert in this case when you control string in 100% I think string replacement is ok. But generally you have right.
– BWA
Nov 20 '18 at 12:37
All such tools have a chance of flagging something as wrong where you know more about the situation. As long as you have made sure that the database name isn't something the user can type in directly and that is from a verified and secure source, then you should tell Sonar to ignore this particular statement.
– Lasse Vågsæther Karlsen
Nov 20 '18 at 12:39
2
Suppressing is a solution. These tools are not all-knowing. From your question, I can't know if the string is indeed properly vetted by the application, and neither can Sonar, hence the warning. If you, the developer, know this string is fine, then you have to suppress, because the database name is not parameterizable in T-SQL. Removing it from the statement means rewriting code.
– Jeroen Mostert
Nov 20 '18 at 12:41