Common vulnerabilities for WinForms applications

Question

I'm not sure if this is on-topic or not here, but it's so specific to .NET WinForms that I believe it makes more sense here than at the Security stackexchange site.

(Also, it's related strictly to secure coding, and I think it's as on-topic as any question asking about common website vulnerabilities that I see all over the site.)

For years, our team has been doing threat modeling on Website projects. Part of our template includes the OWASP Top 10 plus other well-known vulnerabilities, so that when we're doing threat modeling, we always make sure that we have a documented process to addressing each of those common vulnerabilities.

Example:

SQL Injection (Owasp A-1)

• Standard Practice
  • Use Stored Parameterized Procedures where feasible for access to data where possible
  • Use Parameterized Queries if Stored Procedures are not feasible. (Using a 3rd party DB that we can't modify)
  • Escape single quotes only when the above options are not feasible
  • Database permissions must be designed with least-privilege principle
  • By default, users/groups have no access
  • While developing, document the access needed to each object (Table/View/Stored Procedure) and the business need for access.
  • [snip]

At any rate, we used the OWASP Top 10 as the starting point for commonly known vulnerabilities specific to websites.

(Finally to the question)

On rare occasions, we develop WinForms or Windows Service applications when a web app doesn't meet the needs. I'm wondering if there is an equivalent list of commonly known security vulnerabilities for WinForms apps.

Off the top of my head, I can think of a few....

• SQL Injection is still a concern.
• Buffer Overflow is normally prevented by the CLR, but is more possible if using non-managed code mixed in with managed code
• .NET code can be decompiled, so storing sensitive info in code, as opposed to encrypted in the app.config...

Is there such a list, or even several versions of such a list, from which we can borrow to create our own? If so, where can I find it?

I haven't been able to find it, but if there is one, it would be a great help to us, and also other WinForms developers.

Answer 1

There is a big difference between a web environment and a desktop environment. When developing web sites and services, the thing you don't trust is the user (user input). When running a desktop application, the thing that isn't trusted is the application itself, or atleast, a system administrator would like to know whether the application itself doesn't do any harm, since code the runs on the local computer is a risk by itself.

So in a sense, for you as a developer of a desktop application, security rules not always apply, since the application you run is not a black box, but a white box. With a web service / site, you expect attacks to not be able to change the internal state, but with any desktop app (Java, .NET, native) it is 'quite' easy to change the state of the application while the application is running and especially with Java and .NET, debugging and decompiling an application is quite easy.

In other words, you must consider the desktop application completely compromised, and if this is a risk, you must extract everything that must be secure (authentication, authorization, validation) to an external (web) service. For this service, the 'normal' OWASP rules apply.

Things you should watch, is that it's really hard to completely secure your data layer, when a desktop application connects directly to a database. For instance, SQL injection is not an issue for your desktop application in this case, since when the application can directly connect to the database, so can the user. And if the user can connect to the database, he can execute any arbitrary query. This is an extreme form of SQL injection, but it completely skips your application.

Trying to secure a 2 tier application, often means the use of stored procedures as intermediate (service) layer (and preventing direct access to tables). Developing and maintaining stored procedures is much more costly than developing a .NET (web) service.