BugTracker.NET
-
If you are looking for a free .NET based, open-source bugtracking system then look no further than BugTracker.NET[^] It is free, you get the full source-code, there is an active community that can help with your questions should you need help (including the author Corey Trager). It has seamless integration with many version control systems inc. Mercurial and Subversion, giving you the ability to check the changes made against a defect. The Subversion integration is a Python script. If you would rather use something written in .NET then I developed my own which I have uploaded onto Github[^] It can also be themed and styled with your corporate branding. I use this and can highly recommend it :)
We used this for ages and as a simple tool is was a fine, if basic, tool.
cheers Chris Maunder
-
If you are looking for a free .NET based, open-source bugtracking system then look no further than BugTracker.NET[^] It is free, you get the full source-code, there is an active community that can help with your questions should you need help (including the author Corey Trager). It has seamless integration with many version control systems inc. Mercurial and Subversion, giving you the ability to check the changes made against a defect. The Subversion integration is a Python script. If you would rather use something written in .NET then I developed my own which I have uploaded onto Github[^] It can also be themed and styled with your corporate branding. I use this and can highly recommend it :)
Is that the same BugTracker.NET that's currently being discussed on the MSDN blogs? http://blogs.msdn.com/b/cdndevs/archive/2014/09/12/evolving-asp-net-apps-introduction.aspx[^] http://blogs.msdn.com/b/cdndevs/archive/2014/09/19/evolving-asp-net-apps-evaluating-the-code.aspx[^] http://blogs.msdn.com/b/cdndevs/archive/2014/09/26/evolving-asp-net-apps-moving-to-a-web-application.aspx[^] The mention of SQL Injection vulnerabilities in part 2 was enough to put me off. X|
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Is that the same BugTracker.NET that's currently being discussed on the MSDN blogs? http://blogs.msdn.com/b/cdndevs/archive/2014/09/12/evolving-asp-net-apps-introduction.aspx[^] http://blogs.msdn.com/b/cdndevs/archive/2014/09/19/evolving-asp-net-apps-evaluating-the-code.aspx[^] http://blogs.msdn.com/b/cdndevs/archive/2014/09/26/evolving-asp-net-apps-moving-to-a-web-application.aspx[^] The mention of SQL Injection vulnerabilities in part 2 was enough to put me off. X|
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Richard Deeming wrote:
The mention of SQL Injection vulnerabilities in part 2 was enough to put me off.
Because you wanted to expose your bug tracking tool directly to the internet?
Would you implicitly trust all of your employees to have complete control of the bug database? :rolleyes:
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Would you implicitly trust all of your employees to have complete control of the bug database? :rolleyes:
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
In terms of SQL injection attacks??? Then yes. In the last two companies I was the only one with enough SQL experience to do anything real in a SQL database. In the company before that there were probably between 2 and 10 developers with that sort of experience but I would not really expect them to spend their time figuring out how to attack the bug database (that company had very serious big money attack targets.)
-
In terms of SQL injection attacks??? Then yes. In the last two companies I was the only one with enough SQL experience to do anything real in a SQL database. In the company before that there were probably between 2 and 10 developers with that sort of experience but I would not really expect them to spend their time figuring out how to attack the bug database (that company had very serious big money attack targets.)
But if the bug database is on the same server as your attack targets... :~ I'd generally try to avoid leaving any security vulnerability open to any target audience, no matter how unlikely they are to try to exploit it. After all, SQLi is so simple, even a 3 year old can exploit it[^].
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
But if the bug database is on the same server as your attack targets... :~ I'd generally try to avoid leaving any security vulnerability open to any target audience, no matter how unlikely they are to try to exploit it. After all, SQLi is so simple, even a 3 year old can exploit it[^].
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Richard Deeming wrote:
But if the bug database is on the same server as your attack targets
You have big money targets which are on the same server and database as your bug database?
Did you not notice the word "if"? ;P You'll not only need to make sure your bug database is the only application and database on the server; you'll also need to make sure that the SQL service account is locked down, and that the server isn't part of your domain. Otherwise, a breach of that server would compromise your entire network. You'll also need to keep detailed audit logs to track any unauthorised changes to the system. Unless, of course, you don't care about that, in which case you might as well not bother with any authentication or authorization, and just give the users direct admin access to the server. All of which you wouldn't need to worry about if the front-end application was written properly in the first place.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Did you not notice the word "if"? ;P You'll not only need to make sure your bug database is the only application and database on the server; you'll also need to make sure that the SQL service account is locked down, and that the server isn't part of your domain. Otherwise, a breach of that server would compromise your entire network. You'll also need to keep detailed audit logs to track any unauthorised changes to the system. Unless, of course, you don't care about that, in which case you might as well not bother with any authentication or authorization, and just give the users direct admin access to the server. All of which you wouldn't need to worry about if the front-end application was written properly in the first place.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Richard Deeming wrote:
You'll not only need to make sure your bug database is the only application ...
Err...No I would (and have done so) make sure that the bug database and the production boxes had absolutely no commonality. And I would do that regardless of how trustworthy/stable I thought the bug database was.
Richard Deeming wrote:
All of which you wouldn't need to worry about if the front-end application was written properly in the first place.
If there is no commonality at all then I don't need to worry about if the front-end application was written properly in the first place. Which was in fact my point from the beginning.
-
But if the bug database is on the same server as your attack targets... :~ I'd generally try to avoid leaving any security vulnerability open to any target audience, no matter how unlikely they are to try to exploit it. After all, SQLi is so simple, even a 3 year old can exploit it[^].
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Quote:
I'd generally try to avoid leaving any security vulnerability open to any target audience, no matter how unlikely they are to try to exploit it
Such as using the Internet ;)
