SQL Server Security - SQL Injection

For the past year I've been working on security policies and procedures. One of the most challenging part of security is knowing which technology and best practice to use. In my case, I tried all avenues including books, forums,etc. and asked relevant questions then worked myself from top to bottom, meaning from Policies to the procedures, then formulated a plan which included securing the SQL Server database.

One of more common security threat to SQL database is SQL Injection. This is a hacking method that allows an unauthorized attacker to access a database server then executes SQL queries. Once the attacker gains access to the database, he/she is then free to export, add, modify, or delete content from the database. If the hacker is very knowledgeable of other hacking tools, he can penetrate past the database server and into the operating system which could harm the whole system.

To secure your company data against SQL Injection attacks, administrators should implement the principle of least privileged access, granting users rights to part of the applications required for them to their daily work. If their sole purpose is to extract user information, limit permissions to a SQL account used by them to SELECT on target database objects. Another approach to limiting access rights is implementing application roles.

Unfortunately, Microsoft Dynamics Great Plains don't use application roles but uses Database Roles. One of the pain in Great Plains database design is the DYNGRP database role. Here's a classic example:

A company needs to create a new user for an external auditor who wants to access Great Plains, run Reports and do Inquiries. The best way to do this was to create the user in Great Plains, go to SQL Enterprise Manager-Security then open the user's Properties. When you go to the Database Access tab, you can mark db_datareader then the user can only do SELECT statements on the database BUT DYNGRP premissions override the db_datareader option. Being a member of DYNGRP gives users access to run all of the SQL commands and they need to be in that group to even be able to log into Great Plains.

The solution from Great Plains about this security flaw was either to modify the field level security on each window and remove access to the save button OR just give them access to Inquiry and Reports window only.

How about SQL Injection on web-applications? The solution is to build web applications and consider security during design, not post-release. Analyze the resulting error messages from malformed sql statements, ensure that you make them as generic as possible. Download the latest patches and use Microsoft Baseline Security Analyzer(MBSA).

GP Product Report III

PROBLEM REPORT:
The bug ID or problem report number is 18409. Title is 'The payment number is not reserved in Receivables Management' message. This applies to all versions of Great Plains eEnterprise including 9.0.

COMMENTS:
When you create a sales invoice from an order with Credit Card, Check or Cash payment and try to post the document, you'll receive an error in the sales edit list - 'The payment number is not reserved in Receivables Management'.

MBS would send you a fix by deleting & recreating RM00401 but it only worked once in my case. The solution would be to:
1) Remove the sales payment on the invoice then Save
2) Enter the same sales payment on the invoice then Save
3) Delete the General Ledger entries because when the sales payment was entered the first time the entries were also posted. If you post the sales payment distribution entries, this would create a duplicate entry

NOTE: If you're trying to remove a sales payment on a previous year, make sure you open the Financial & Sales module on that month/year.