Practical Security
for Intranet Applications
Acorns under
the pillow??
Just
because your application lives & breathes safely on this side of the firewall,
safe from intruders, doesn't mean you should sleep easy. Sensitive information
still needs to be kept from prying eyes, disgruntled employees, and anyone who
has less than noble intentions. In this webcast we covered the types of threats
as well as the remedies to lock down information to keep it safe.
Some links
to useful information about the topics we covered include the following:
Encryption
The .NET
Framework supports the following encryption algorithms in the
System.Security.Cryptography namespace:
Intranet Security Best Practices
Even
IntraNet application should follow some of the basic best practices, especially
since the threats faced by the applications are internal. This means that you
need to think about the code as well as every other asset of the application.
Here are some of them:
-
Use
Code Behind. If code is
mixed in with the html, and those files are exploited, then the attacker
will be able to use the information to their advantage. When an application
is put on a production server, even if it is internal it is better to deploy
as assemblies...
-
Obfuscate. This is the process of making the assembled code less
readable and simply raises the bar
-
Encrypt sensitive data where it is stored. Anyone with Access or MS
Query can read data from a table that doesn't have permissions set on it,
especially if there are legacy accounts that don't change their passwords
very often, yet are granted dbo privileges.
-
Limit access to your data. Grant access where appropriate, granting read
to those how need it.
-
Use
Stored Procedures. Five good reasons:
-
Better Performance. The execution plan is precompiled, the database
engine doesn't have to recompile each time
-
Security. Because the stored procedure checks input parameters for type
you're protected from SQL Injection attack
-
Manageability. Stored Procedures live in the database instead of in the
applications. Instead of relying on multiple developers to follow business
rules they can be implemented where the data lives
-
DBA
Integration. Developers generally think in procedural ways of
accomplishing things. By leveraging your local DBA you're getting someone
who thinks & works with Set Calculus regularly and you're more likely
(hopefully) to get better code
-
You
look like a hero. Because you followed best practices when someone else
comes along to support your application they'll be glad you did...
-
DO
NOT ALLOW APPLICATIONS TO REQUIRE THE SA ACCOUNT. Because as soon as the
SA account is used you are limited in the ability to manage it's password.
-
Use
Trusted Connections. This way you don't have to store the User ID &
Password in the Web.Config file (which may or may not be secure)
-
Set
proper Access on the File System. Use the ACL (Access Control List) to
limit who has rights to directories containing application files. If the
"Everyone" group has read rights to the directory, they can open the
Web.Config file to look for passwords...See your TechNet guy for help
Other
Security Resources. Stay informed about security...
|
