12

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.

David
  • 72,686
  • 18
  • 132
  • 173
  • That's a very interesting question. I'm not sure how the community at large will feel about the on-topic-ness of your question for SO but it's a good question nonetheless. – Mike Dinescu Jul 05 '12 at 14:45
  • How is your desktop application deployed? Are you handing this application out to anyone who wants it, or is it limited to trusted individuals on-site? – JDB Jul 05 '12 at 14:51
  • It's for internal use within our company. We are in the Retail business with a fairly large number of retail locations (stores). The application is deployed using configuration management software, but in essence it's a simple XCOPY deployment. We do trust our co-workers, but with several thousand co-workers at these sites, the risk of insider attacks is always there. The apps we create may or may not deal with sensitive info. Our template includes a check box for "N/A" so on non-secure apps, we may not worry about all the items on the list. We just want a good list to start with. – David Jul 05 '12 at 14:55

3 Answers3

12

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.

Steven
  • 166,672
  • 24
  • 332
  • 435
  • That makes sense. I suppose it translates over to the web world an a way: The browser is considered completely untrusted, and it's my job to ensure that my website isn't going to give up any secrets because of the browser. My WinForms app, like my customer's web browser, is "out of my control". I have to plan, assuming that my Winforms app is completely untrustworthy, and therefore move any business logic that need to be protected off to my web services, and use the WinForms app stricly as the UI. Is that an accurate paraphrase? – David Jul 05 '12 at 17:19
  • Absolutely. Also note that SQL databases are often attacked using buffer overflow attacks. So if you can (again) hide your db behind a web service. – Steven Jul 05 '12 at 19:15
  • I can't argue with that logic, and I never thought of it that way before, even though I know how simple it is to decompile and reverse-engineer a .NET app. Thank you. – David Jul 05 '12 at 19:56
  • Don't just mark me as answer just yet. I like to see what others have to say about this. – Steven Jul 06 '12 at 04:39
  • Nice answer Steven, but I think OP not only wants SQL Injection but all kinds of flaws, or? – Mare Infinitus Jul 06 '12 at 08:20
  • @MareInfinitus: Can you come up with flaws that actually matter in a WinForms app? – Steven Jul 06 '12 at 08:25
  • many excuses. you already wrote that there has to be made a distinction between web und desktop. perhaps I have understood something wrong in the first place. – Mare Infinitus Jul 06 '12 at 11:47
  • @MareInfinitus: Excuses not needed. I asked David to unmark my answer, because I hope more people will answer this question and I'm curious if we can come up with scenarios where security flaws do matter. One I can think of is when the app downloads and installs new updates over an untrusted line and accepts unsigned (or wrongly signed) dlls. – Steven Jul 06 '12 at 12:20
  • Unmarked as requested. I am definitely interested in what others have to say. – David Jul 06 '12 at 12:28
4

Perhaps you want to investigate on existing tools that check for security vulnerabilities. They have sometimes lists of the flaws they will check.

There are still all possible security risks in managed code, as a developer can open all kinds of holes. The framework (.NET) is not a risk on it's own, but the developer is.

Here you have a list of tools, you can read there which security risks they will check for:

Static code analysis list

But, of course, there are known vulnerabilies, as you can see here:

technet remote code execution

technet elevation of priviledge

There are more known and not solved flaws, which can be found at the well known security sites. (including zero day exploits)

** MORE DETAILED INFORMATION, it was the checklist i mentioned in the comment **

MS Security checklist (do not know why this is "retired" as this are mostly neutral infos

Open Web application security project

MS Anti cross-site-scripting

MS ASP security reference implementation (very good information site)

CAT.NET ... MS static security analysis tool

Mare Infinitus
  • 8,024
  • 8
  • 64
  • 113
  • +1 because these tools definitely have a place, but these are a separate set of tools from what I'm thinking of. Our threat analysis server a few purposes. *One* of them is to educate new developers as they join the team - having that list of things to watch for and how to handle them is a bit of a training tool, so we want to use code analysis tools *in addition to* performing threat modeling and other activities. This is great, but a separate set of controls from what I was asking for. – David Jul 06 '12 at 12:30
  • Put another way, these are good tools for finding flaws in existing code. We're looking for a list of things to be aware of so that we can plan the software to avoid these before a single line of code is written. – David Jul 06 '12 at 13:12
  • Okay, I understood the question in another way. You want to know which things to avoid to be on a way that has no security flaws from the beginning, right? Think I read such a list some months ago, have to dig around a little... – Mare Infinitus Jul 06 '12 at 17:00
1

I'm afraid it's impossible to build a local winform app which is actually secure since the users can always crack your apps.

But there are some techniques to slow the cracking process. Most of the techniques happened on assembly layer, e.g. junk codes and packings.

Another technique is to make your executable codes(i.e. codes that comes into the memory when the program is being executed) varies with time. However you must first ensure that all other codes(which is not executed then) are safe. This can be done by encryption. But you must also make sure that the encryption program is more highly secured. The encryption program is always fixed in ROM and secured by physical means.

Another way is to take the advantage of the network. Update the local apps often and forbid the older versions. In this way, your code may varies quickly enough to beat the cracking process.

oh...am I throwing rubbish or is it just off-topic? My apology.

kwjsksai
  • 337
  • 1
  • 4
  • 15