3

I believe that most people here are familiar with OWASP and their Top 10 project. When it comes to information systems these days it appears that there is a big focus on web application security and rightfully so. Recently I was tasked to perform a Risk Analysis on an Information System (SQL Server 2005) that has user application interfaces which are both Web and Non Web. So far I have found a lot of very good articles and tools that show web threats and vulnerabilities, but not so much on non-web based applications.

Does anyone know of any good resources that explain and test the vulnerabilities/risks of non-web interfaces of information systems? These applications are run on Windows machines.

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
RedZeppelin1977
  • 31
  • 2
  • What APIs and communications methods are the non-web clients connecting over? (You may even find they use web APIs!) – Graham Hill Feb 13 '12 at 15:44
  • Specifically the Non-Web users have workstations running XP that are connected to an internal network. These users have access to a Windows Application developed in C Sharp to communicate with the database. I did not create this application but I have been tasked to define threats and vulnerabilities of this type of interface. This is the first risk analysis I have performed so please let me know if I the questions I am writing are making sense. The Win App connects to the database via a connection string that passes the appropriate credentials to access that particular database. Thanks – RedZeppelin1977 Feb 13 '12 at 16:59
  • 2
    You looking for Threat Modeling , PT or both? To start with use the checklist from MSDN and Threat Modeling tool from Microsoft( as this is your first one). These two will give you directions to what to look for. and for PT just search "Thick CLient Penetration Testing" you will get a lot of resources – Sachin Kumar Feb 13 '12 at 17:44
  • Yeah I am looking for both. I will definitely check this out. Thanks – RedZeppelin1977 Feb 13 '12 at 18:43

2 Answers2

3

As Sachin Kumar pointed out, you should probably start doing some Threat Modelling. The leading resource in this respect is the Microsoft Security Development Lifecycle book/resource. This does not mean this only applies to Microsoft environments or software. In fact, it is a very generic methodology which works pretty well for any kind of application. The Threat Modelling Tool itself isn't really necessary. It just helps putting the data together. I find it easier to just use pen and paper though, unless it's an extremely complex setup.

The idea (extremely briefly) behind this methodology, is to first of all map out the Data Flows, using a DFD (Data Flow Diagram), and then apply the STRIDE classification of threats for each component of the DFD. Once you did that, and really thought about each potential threat carefully, it should already give you a pretty good idea what the main problems are and could help you focus on what to look for. You can also use DREAD to rate those issues in terms of priority/risk. Although if you have some experience you would know the rating almost instinctively. DREAD is a bit too detailed for most cases anyway.

Actually testing for real vulnerabilities or issues can be the next step, but it depends on the environment and the skill-set involved in actually performing it. Another approach that can give you a lot of added value is doing some security code review (if you have access to the code). Or if you have some security static code analysis tools, those can help a lot too.

Yoav Aner
  • 5,299
  • 3
  • 24
  • 37
2

In terms of SQL specifically, you will always have injections as a threat vector. At the host or on the network (if there is no encryption) they can manipulate data for a SQL injection or any any type of escalation attack, buffer overflow etc. The main issue is you are receiving data and must make sure your code does some sanitization or white listing.

You may also want to check out hardening guides, like those from the Center for Internet Security: https://benchmarks.cisecurity.org/en-us/?route=downloads.multiform

OWASP SQL injection guidelines still apply even if not a web layer.

The Win App connects to the database via a connection string that passes the appropriate credentials to access that particular database.

I would say you would want to determine if this connection is encrypted or not or how the credentials are otherwise protected. You might also want to profile the SQL server itself in terms of are the patches up to date, is the data in the database stored with enough security - is PII stored encrypted, obfuscated, truncated, or tokenized, etc.

It sounds like you might want to focus on threats to a MS SQL server rather than the specific application to start. From the application stand point, can a user elevate his privileges or set queries that will leak out information beyond their privileges?

Eric G
  • 9,691
  • 4
  • 31
  • 58