Code Security Thoughts

[Antony]

I am currently writing an application (VB.NET) and I was thinking about all
the hype that seems to be given to security and if I should pay it any
attention or not.

My first thought was, nah, no need to worry about security because my app
will not include WEB services, thus won't be hosted, thus should not be
vulnerable for attack.

But then I thought, what happens if some hacker gets into a machine where my
app is running, finds a DLL called <appname>.DataAccess.DLL, for example,
and decides that sounds interesting? In theory, couldn't a hacker copy my
DLL to their machine, and assuming they've got some sort of .NET framework
development tool, add a reference to my DLL, which will provide them with a
list of functions, properties, etc. inside my DataAccess DLL? Going on from
that, if they're good in enough to get in in the first place, they could
write some code which makes use of functions inside my DLL, run it on the
machine where my app is running and update the DB?

I've seen a bit of documentation about coding securely, but don't really
understand it and didn't have much interest in it until I started thinking
about the above scenario (probably obvious from this post).

Am I completely off the track on this, or somewhat close to it? Any
suggestions on what more experienced developers do to code securely?

Thanks for your time.

Regards
Antony

 

[Guest]

There are a lot of answers to your question but here's my take on it.
Hopefully I won't get beat up too badly.

You have to be aware of security when you code, definitely. On the other
hand, you have to look at your environment. Is this code for your personal
machine to manage your Orchid plant collection or is this an internet app
exposed to the masses? If it's a corporate app - how sensitive is the data
and what is your corporate culture? You said your app would not be internet
facing but what about in the future? A little time spent now thinking about
and applying general security principals will make it easier in the future to
make any changes required to expose the product.

If you have the luxury of using Windows Integrated Authentication on your
internal network then I would highly recommend doing that. Even if a hacker
(which would likely be an internal hacker or nosey person) gets ahold of your
..dll, that person would need to already have access to the data through their
login to gain access to the data. You're not going to allow them access
simply by their use of the .dll.

If you need to embed a username and password in the .dll, find some way to
encrypt or obsfucate it. Decompilers are common and easy way to look at the
information in your source code. Again, consider the use. If the data is not
sensitive and you don't mind if someone spends the time to decompile and
figure your code out, don't waste the time encrypting. By embedding a
username and password in a dll, you're just keeping honest people honest for
the most part anyway.

Making a user enter a username and password at the start of your app is an
annoyance, but one way to get around embedding security information in the
..dll. Alternately you could use an application service account to get to the
data and then lookup the user based on Windows logon information, PC name,
whatever. Of course there are network sniffer issues, memory monitoring
concerns, etc... it never ends.

Do the best you can and spend the rest of the time writing more code. If you
find a problem, fix it, change your thought process going forward and move on.

 

[Antony]

Thanks Mike!

There are a lot of answers to your question but here's my take on it.
Hopefully I won't get beat up too badly.

You have to be aware of security when you code, definitely. On the other
hand, you have to look at your environment. Is this code for your personal
machine to manage your Orchid plant collection or is this an internet app
exposed to the masses? If it's a corporate app - how sensitive is the data
and what is your corporate culture? You said your app would not be
internet
facing but what about in the future? A little time spent now thinking
about
and applying general security principals will make it easier in the future
to
make any changes required to expose the product.

If you have the luxury of using Windows Integrated Authentication on your
internal network then I would highly recommend doing that. Even if a
hacker
(which would likely be an internal hacker or nosey person) gets ahold of
your
.dll, that person would need to already have access to the data through
their
login to gain access to the data. You're not going to allow them access
simply by their use of the .dll.

If you need to embed a username and password in the .dll, find some way to
encrypt or obsfucate it. Decompilers are common and easy way to look at
the
information in your source code. Again, consider the use. If the data is
not
sensitive and you don't mind if someone spends the time to decompile and
figure your code out, don't waste the time encrypting. By embedding a
username and password in a dll, you're just keeping honest people honest
for
the most part anyway.

Making a user enter a username and password at the start of your app is an
annoyance, but one way to get around embedding security information in the
.dll. Alternately you could use an application service account to get to
the
data and then lookup the user based on Windows logon information, PC name,
whatever. Of course there are network sniffer issues, memory monitoring
concerns, etc... it never ends.

Do the best you can and spend the rest of the time writing more code. If
you
find a problem, fix it, change your thought process going forward and move
on.