N342 Security and Risk
|
Modified:
|
There are two sides to security from a Web developers viewpoint, the client and the server.
The client side
issues fall into the following categories:
- Safe access of Web resources - well-behaved browsers, plug-ins,
applets, ActiveX controls, etc. that do not corrupt the client system.
Includes deliberate and unintentional corruption. Addressed by language design
(Java applets), trusted sources (intranet, certified software developer,
trusted name), proxy servers that limit or filter access to Web, virus
detection software, refusal to open active documents such as OutLook, Word,
etc.
- Secure communications - sensitive data that can be transmitted
between client and server securely. Addressed by secure protocols such as SSL.
The server issues are generally:
- Secure data - access to sensitive data stored on the server is
restricted and the data is encrypted. Addressed by administrative procedures
and encryption software.
- Secure communications - sensitive data can be transmitted between
client and server. Addressed by secure protocols such as SSL.
- Safe operation of server - the server and system are secured
against unintended use. Includes deliberate and unintentional corruption.
Addressed by administration of server to restrict client access, careful
implementation of server side programs, restriction of execution privileges to
trusted developers, firewalls to limit Web access to server, monitoring access
log, data encryption etc.
Secure access
The success of many attacks is due to program flaws or poor
implementation of security.
Securing access to data commonly includes verification of some form of
user credentials, such as a login/password.
Further measures should include preventing common methods used to breach
program or data integrity.
SQL Injection -
http://en.wikipedia.org/wiki/SQL_injection
SQL injection can occur whenever user input, such as from a form, is
directly used to construct a SQL statement.
Suppose the CartCommit.asp script accepted user entered text in
an SQL statement:
| username = Request("username"); rs =
conn.Execute("SELECT * FROM Cart where
ID='"+username+"'"); |
Ray as input results in SQL of:
| SELECT * FROM Cart where ID='Ray' |
O'Brien as input results in SQL of:
| SELECT * FROM Cart where ID='O'Brien' |
causing the SQL to fail and probably crash the program.
Other inputs could delete all the table records, note that -- is an
SQL comment:
x'; DELETE FROM TRADER;--
| SELECT * FROM Cart where ID='x';
DELETE FROM TRADER;--' |
Attackers can easily determine if your programs are subject to SQL
injection by making them fail. A little more effort and some lucky
guesses can accomplish serious damage.
Note that the following, because no user input is used to construct
the SQL statement, is not subject to SQL injection.
| conn.Execute("DELETE FROM Portfolio WHERE SHARES=0"); |
The following seems safe because Session("trader")
is a cookie, there is no direct user input.
| conn.Execute("DELETE FROM Cart WHERE ID='"+Session("trader")+"'"); |
However, if user input was used directly when registering the trader
SQL injection is still possible.
Variable binding
To deter injection, the fixed and variable parts of the SQL can be separated by the following:
var cmd = Server.CreateObject("ADODB.Command");
cmd.ActiveConnection = conn;
cmd.CommandText = "SELECT * FROM Cart WHERE ID = ?";
cmd.CommandType = 1;
// name, type, direction, size, value
cmd.Parameters.Append( cmd.CreateParameter ("ID", 200, 1,
username.length, username));
rs = cmd.Execute(); |
See
CreateParameters for further information.
The SQL is defined as the command text where the ? acts as a formal
parameter in:
| cmd.CommandText = "SELECT * FROM Cart WHERE ID = ?"; |
The user input is defined as an actual parameter username that
replaces the ? at execution:
| cmd.Parameters.Append( cmd.CreateParameter ("ID", 200,
1, username.length, username)); |
User input of:
'; DELETE FROM TRADER;--
would cause no issues, being processed as the ID value with quotes
part of the value not delimiters, as:
| SELECT * FROM Cart WHERE ID = '; DELETE FROM TRADER;-- |
Microsoft Access
Microsoft Access does not allow multiple SQL statements in a single
input.
While preventing execution of:
| SELECT * FROM Cart where ID='x';
DELETE FROM TRADER;--' |
the statement would fail in Access and potentially crash the
application.
Security Overview
Security consists of three interdependent elements:
· Authentication
as proof of identity.
We need to know a site claiming to be www.search.com actually is
www.search.com.
Generally, we require some trusted
third-party authority that can not only verify an identity but also ensure that
the verification is trustworthy.
· Encryption
transforms an easily read message into a form that, without knowledge of the
transformation, is more difficult to read.
Decryption transforms the encrypted
message back to a readable form.
Caesar's Cipher is
based on substituting each letter with one a fixed distance in the alphabet.
For a distance of 2, the message: ABCD would be encrypted as:
CDEF
· Verification
determines whether the message has been received as it was sent; no tampering
has occurred.
Resources:
- Symmetric Key Systems
- Public Key Systems
- http://en.wikipedia.org/wiki/Public-key_cryptography
- Secure Sockets Layer
- http://en.wikipedia.org/wiki/Transport_Layer_Security
- Hash
- Key Distribution Center
- http://msdn.microsoft.com/en-us/library/aa378170(VS.85).aspx
- SATSA
- Introduction - http://java.sun.com/j2me/docs/satsa-dg/index.html
- Crypto - http://java.sun.com/j2me/docs/satsa-dg/crypto.html
- Everything
VERIFICATION
Hashing - Used to verify that the message sent is the message
received.
A hash maps input (such as a message text) to some number.
For example, a modulus 256 hash could operate by:
Sum the byte values of the message, the sum will be a value between
0-255.
SHA-1 (Secure Hash Algorithm 1) developed by NSA processes 512-bit
blocks to produce a 160-bit hash. Very difficult to change the message
and produce the same hash.
Verification process:
Sender computes hash of message and sends along with message.
Receiver recomputes hash, if agree with sent hash assumed message
verified.
Verification by Hashing (Message Digest) - Used to verify that the message sent is the message
received.
- A hash maps input (such as a message text) to some number.
- John Smith hashes to the number 01.
- john Smith unlikely to hash to 01.
- For example, a modulus 256 or 8-bit hash could operate by:
Sum the byte values of the message.
The hash (sum) will be a value between
0-255.
- Passwords are often hashed and the hash stored for log-in verification.
Cryptographic hash functions are designed to be irreversible.
- Example
Registration:
- User registers password.
- Password hashed and stored.
Login
- User enters password.
- Password hashed.
- Compared with stored hash.
- Verification of communication:
Sender computes hash of message and sends along with message.
Receiver recomputes hash of message, if agrees with sent hash assumed message
verified.
- Example
Sender message includes hash.
Man-in-the-middle changes message and recomputes hash.
Receiver cannot detect tampering.

Microsoft File Checksum Integrity Verifier (FCIV)
Utility
File Checksum Integrity Verifier (FCIV)
is command-line utility that computes and generates MD5
or SHA-1 cryptographic hash values for files to compare
the values against a known good value to verify that the
files have not been changed.
Features of the FCIV utility:
- Supports MD5 or SHA1 hash algorithms (The
default is MD5.)
- Can output hash values to the console or store
the hash value and file name in an XML file.
- Can recursively generate hash values for all
files in a directory and in all subdirectories (for
example, fciv.exe c:\ -r)
- Supplies an exception list to specify files or
directories to hash.
- Can store hash values for a file with or without
the full path of the file.
To display the MD5 hash of a file named readme.txt, type the following
command at a command prompt:
fciv.exe readme.txt
| 79ac8d043dc8739f661c45cc33fc07ac
readme.txt |
To display the SHA-1 hash of a file, use the
following command:
fciv.exe -sha1 readme.txt
| 2fe398f1ebced166087362626241b95efeaab407
readme.txt |
Readme.txt
Microsoft (R) File Checksum Integrity Verifier V2.05 README file
================================================================
1.What is File Checksum Integrity Verifier (FCIV)?
2.Features.
3.Syntax.
4.Database storage format.
5.Verification.
1.What is fciv?
---------------
Fciv is a command line utility that computes and verifies hashes of files.
It computes a MD5 or SHA1 cryptographic hash of the content of the file.
If the file is modified, the hash is different.
With fciv, you can compute hashes of all your sensitive files.
When you suspect that your system has been compromised, you can run a verification to determine which files have been modified.
You can also schedule verifications regularily.
2.Features:
-----------
- Hash algorithm: MD5 , SHA1 or both ( default MD5).
- Display to screen or store hash and filename in a xml file.
- Can recursively browse a directory ( ex fciv.exe c:\ -r ).
- Exception list to specify files or directories that should not be computed.
- Database listing.
- hashes and signature verifications.
- store filename with or without full path.
3.Syntax:
---------
Usage: fciv.exe [Commands]
Commands: ( Default -add )
-add : Compute hash and send to output (default screen).
dir options:
-r : recursive.
-type : ex: -type *.exe.
-exc file: list of directories that should not be computed.
-wp : Without full path name. ( Default store full path)
-bp : base path. The base path is removed from the path name of each entry
-list : List entries in the database.
-v : Verify hashes.
: Option: -bp basepath.
-? -h -help : Extended Help.
Options:
-md5 | -sha1 | -both : Specify hashtype, default md5.
-xml db : Specify database format and name.
To display the MD5 hash of a file, type fciv.exe filename
Compute hashes:
fciv.exe c:\mydir\myfile.dll
fciv.exe c:\ -r -exc exceptions.txt -sha1 -xml dbsha.xml
fciv.exe c:\mydir -type *.exe
fciv.exe c:\mydir -wp -both -xml db.xml
List hashes stored in database:
fciv.exe -list -sha1 -xml db.xml
Verifications:
fciv.exe -v -sha1 -xml db.xml
fciv.exe -v -bp c:\mydir -sha1 -xml db.xml
4.Database storage format:
--------------------------
xml file.
The hash is stored in base 64.
5.Verification:
---------------
You can build a hash database of your sensitive files and verify them regularly or when you suspect that your system
has been compromised.
It checks each entry stored in the db and verify that the checksum was not modified.
|
Using a hash (digest) to send a password to a server
- Create a message digest value from the clear-text password but do not
send the password.
An
attacker could just steal the digest value, of course.
Add some other data to the digest as well so that only the server, knowing
the password, can recreate the same digest value.
- Client generates a timestamp and a random number and, along with the user name and the password,
creates the message digest .
- Client sends the clear-text user name, the timestamp, the random
number, and the digest value to the server.
It does not send the
password as clear-text, but the password was used to calculate the digest
value.
- The server takes the user name and looks up the corresponding
password (possibly a hash), which should be stored securely in a file or a database.
The
server repeats the client process, creating a digest value of the user name, password, timestamp, and
random number.
- If the digest value created on the server matches the digest value
sent by the client, then the server knows that only the user
could have typed in
the right password.
| Question: Why the random number? |

Replay attacks
Replay attacks can occur when a man-in-the-middle captures a valid login
sequence and later replays to the server.
The server needs some logic to prevent replay attacks.
Specifically, the
server should reject login attempts that use timestamps and random numbers
that have been used before with that login by:
- Save the timestamp of each user’s last login attempt.
- For each subsequent login attempt, the server looks up the saved
timestamp.
- If the timestamp on the current attempt is more recent than the saved
timestamp, the attempt is allowed.
- The current attempt’s timestamp replaces the saved timestamp for
this user.
| Question: What is to prevent the man-in-the-middle from changing
the time-stamp? |
ENCRYPTION/DECRYPTION
- Symmetric encryption/decryption.
- Encrypt/decrypt message using a shared key.
- Fast.
- Requires shared key.
Secret-key Cryptography - Used for secure data communications.
The same symmetric key encrypts and decrypts plain text message.
A secret-key example is Data Encryption Standard (DES) with a key
length of 56 bits, considered too short for modern code breaking methods.
Work is under way to improve its security.
The
same symmetric key encrypts and decrypts plain text message.
- An early
secret-key example is Data Encryption Standard (DES) with a key length of
56 bits, considered too short for modern code breaking methods.
- International Data Encryption Algorithm (IDEA) is one of many DES
replacements, is a block cipher of a 128-bit key.
- Stream ciphers operate on single bytes, appropriate for interactive
communications (e.g. sending actions in a multiplayer FPS game).
- Block ciphers operate on blocks of bytes, appropriate for message
(e.g. file) communications.
Problem is that both sender and receiver must possess same key.
- One sharing solution is plain old mail
- Another is a key distribution center (KDC) which shares a
temporary, secret key with users on a network.
KDC
- Both sender and receiver would have a
different key to authenticate with the KDC.
- The KDC generates a temporary session key and encrypts
using the sender and receiver keys, then forwards to each respectively.
- The sender
and receiver then decrypt the session key using their own key.
- Recall that the KDC encrypted the session key using their key.
- This also serves to authenticate the KDC since only it should
know their keys.
- Can now use session key for symmetrically encrypted communication.
Kerberos protocol
- A protocol that defines how clients interact with a network
authentication service.
- Clients obtain tickets from the Kerberos Key Distribution Center
(KDC).
- They present these tickets to servers when connections are
established.
- Kerberos tickets represent the client's network credentials.
| Question: Why is a temporary session key used for networked
communication? |
Key Distribution Center from Microsoft
The Key Distribution Center (KDC) is implemented as a domain
service. It uses the Active Directory as its account database
and the Global Catalog for directing referrals to KDCs in other
domains.
As in other implementations of the
Kerberos protocol, the KDC is a single process that
provides two services:
- Authentication Service (AS)
This service issues ticket-granting tickets (TGTs) for
connection to the ticket-granting service in its own domain
or in any trusted domain. Before a client can ask for a
ticket to another computer, it must request a TGT from the
authentication service in the client's account domain. The
authentication service returns a TGT for the ticket-granting
service in the target computer's domain. The TGT can be
reused until it expires, but the first access to any
domain's ticket-granting service always requires a trip to
the authentication service in the client's account domain.
- Ticket-Granting Service (TGS)
This service issues tickets for connection to computers
in its own domain. When clients want access to a computer,
they contact the ticket-granting service in the target
computer's domain, present a TGT, and ask for a ticket to
the computer. The ticket can be reused until it expires, but
the first access to any computer always requires a trip to
the ticket-granting service in the target computer's account
domain.
The KDC for a domain is located on a domain controller, as is
the Active Directory for the domain. Both services are started
automatically by the domain controller's
Local Security Authority (LSA) and run as part of
the LSA's process. Neither service can be stopped. If the KDC is
unavailable to network clients, then the Active Directory is
also unavailable—and the domain controller is no longer
controlling the domain. The system ensures availability of these
and other domain services by allowing each domain to have
several domain controllers, all peers. Any domain controller can
accept authentication requests and ticket-granting requests
addressed to the domain's KDC.
The
security principal name used by the KDC in any
domain is "krbtgt", as specified by
RFC 1510. An account for this security principal is created
automatically when a new domain is created. The account cannot
be deleted, nor can the name be changed. A password is assigned
to the account automatically and is changed on a regular
schedule, as are the passwords assigned to domain trust
accounts. The password for the KDC's account is used to derive a
cryptographic key for encrypting and decrypting the TGTs that it
issues. The password for a domain trust account is used to
derive an inter-realm key for encrypting referral tickets.
All instances of the KDC within a domain use the domain
account for the security principal "krbtgt". Clients address
messages to a domain's KDC by including both the service's
principal name, "krbtgt", and the name of the domain. Both items
of information are also used in tickets to identify the issuing
authority. For information on name forms and addressing
conventions, see
RFC 1510.
Public-key Cryptography - Avoids the secret-key problem of exchanging
a common key.

Based on a private key and an inverse public key.
The public key is used
by the sender to encrypt a message to the receiver, the receiver applies
their private key to decrypt the message.
An example public key might be to square each piece of a message, the
private key would be the inverse, to take the square root of each piece. For example, square to encrypt the message 2 3 4 as 4 9 16 and send,
decrypt 4 9 16 using the square root as 2 3 4.
Generally a key is generated as the composition of two large prime
numbers which are needed for encryption and are difficult to determine given
the key itself.
When both sender and receiver have public keys, the sender can sign a
message using their private key and the receiver decrypt the
signature using the sender's public key to verify the origin.
Problem:
Third party could intercept messages, replace with own. Receiver
needs to verify message was not tampered.
Solution:
Sender computes message hash, signs hash with private key. Sends
message and hash.
Receiver applies sender's public key to hash, recomputes hash of
message, if agree message verified. Note that only the sender could have
signed a hash readable using their public key.
Example
- Public key to
square each byte of a message.
f(x) = x2
- Private key would be to take the square root
of each byte.
x = f(x)1/2 = (x2)1/2
- Encrypt, using receiver's square public key, 2 3 4 and send 4 9 16.
- Decrypt, using receiver's square root private key, 4 9 16 decrypted as 2 3 4.
Keys
Generally a public key is
generated as the composition of two large prime numbers which are needed for
encryption and are difficult to determine given the key itself.
Signing
Both sender
and receiver have public keys.
Sender can sign a message using their private key.
Sender encrypts message and signature using receiver's public key.
Receiver decrypts message using their private key.
Receiver reads signature using the sender's public
key to verify the origin.
Verification
Third party could intercept messages, replace with own using
receiver's public key.
Receiver
needs to verify message was not tampered.
Sender computes message hash, signs hash with private key.
Receiver applies sender's public key to hash, recomputes hash of
message, if agree message verified.
Certification Authorities (CA) - Certify that one is who they claim,
that a public key is associated with a given site.
- Problem of most key systems is that a
customer visiting a commercial site needs the site's public key.
- Possible for a third party to:
- masquerade as reputable site and send self-generated public
key
- as man-in-the-middle, replace a reputable site's public key in message with
their own and receive the customer's information.
- For the site to trust the user identity, each user would need their own
public/private key and certificate.
- Not normally required since they're already getting your money.
- When necessary (e.g. banks) use a login/password, presumably
encrypted using the now certified site's public key.
- A solution is for a trusted
CA to authenticate the commercial site to be who they claim
by providing the site with a certificate containing:
- site's public key
- a hash of the certificate
- CA's own signature generated using the CA's private key
- The customer decrypts the CA signature using the CA public key to
verify authenticity but a third party could replace the site's public
key.
- Customer hashes certificate, if agrees with CA provided hash accept
public key as authentic.
- Customer software would necessarily have the CA public key needed to read
and verify the certification authority's signature.
Data Security
Protection of personal or sensitive data is commonly required by law.
There are several basic approaches to protecting data on the server or
personal machine:
- Restrict access of directories containing sensitive files to only
those users or applications requiring access.
- Encrypt data. Most operating systems (including Microsoft) support
data encryption.
Microsoft
Files or folders can be encrypted and automatically decrypted by the
owner, non-owners must supply the encryption key. Details are at:
http://www.microsoft.com/windowsxp/using/security/learnmore/encryptdata.mspx
PGP
PGP (Pretty Good Privacy) originated as public-domain software to
encrypt/decrypt communications and file encryption using public/private and
symmetric and asymmetric keys. A freeware version is available at: http://www.pgp.com/downloads/index.html
Network Security
Security Holes
- Certificates can be self-certified, security fails if software and/or
user does not verify certificate from a trusted CA.
- CA verification of clients.
- Once encrypted data is received by the server, it is generally decrypted
and often stored, making it accessible as plain text.
Security Protocols
Secure Socket Layer (SSL) is a standard protocol
based on public key technology, certificates and secret-keys.
Transport Layer Security (TLS) succeeded SSL.
- Both are cryptographic protocols that provide security and data
integrity for communications over TCP/IP networks such as the Internet.
- TLS and SSL encrypt the segments of network connections at the
Transport Layer end-to-end.
Hypertext Transfer Protocol Secure (HTTPS)
- HTTP over SSL/TLS for end-to-end secure communications.
- Requires client to accept CA certificate identifying server site in
order to establish SSL/TLS session.
A Secure Transaction
Public key cryptography keys must be long for security, since attackers
have lots of time and public keys must not change often.
Encryption/decryption is slow using long keys.
Using a one-time, smaller secret key for encryption allows for a faster conversion.
Still computationally difficult for attackers to determine message.
To conduct a secure
transaction:
- a customer contacts a commercial site server and sends a random
number
- site sends own random number and its certificate containing public key
- the customer verifies the certificate authenticity through a CA,
often the CA verification data is stored on customer computer.
- negotiates a new secret key with the server using the public
key
- the customer sends a 384-bit premaster key encrypted by
site's public key.
- secret-key derived using the two random numbers and
premaster key.
- Secure communication is then conducted using the shared secret-key
for encryption/decryption and a hash for message integrity.
TLS Handshake - from http://en.wikipedia.org/wiki/Secure_Sockets_Layer
A TLS client and server negotiate a stateful
connection by using a handshaking procedure.
During this
handshake, the client and server agree on various
parameters used to establish the connection's security.
- The handshake begins when a client connects to a
TLS-enabled server requesting a secure connection,
and presents a list of supported
ciphers and
hash functions.
- From this list, the server picks the strongest
cipher and hash function that it also supports and
notifies the client of the decision.
- The server sends back its identification in the
form of a
digital certificate.
- The certificate usually contains the server
name, the trusted
certificate authority (CA), and the server's
public encryption key.
The client may contact the server that issued the
certificate (the trusted CA as above) and confirm that
the certificate is authentic before proceeding.
- In order to generate the session keys used for
the secure connection, the client encrypts a random
number (RN) with the server's public key (PbK), and
sends the result to the server.
- Only the server can decrypt it (with its private
key (PvK)): this is the one fact that makes the keys
hidden from third parties, since only the server and
the client have access to this data.
- The client knows PbK and RN, and the server
knows PvK and (after decryption of the client's
message) the RN.
- A third party may only know PbK, unless PvK has
been compromised.
- From the random number, both parties generate
symmetric key for encryption and decryption
using the agreed upon cipher.
This concludes the handshake and begins the secured
connection, which is encrypted and decrypted with the
symmetric key until the connection closes.
If any one of the above steps fails, the TLS
handshake fails, and the connection is not created.
HTTPS - HTTP over Secure connection
HTTP over a secure connection such as TLS.
Client authentication
- TLS will support client authentication.
- Feature not supported on all clients so may still need separate login password.
Question:
- What port is used for HTTP?
- What port is used for HTTPS?
- Are URLs encrypted under HTTPS?
- Must login data be encrypted when sent over HTTP?
- Must login data be encrypted when sent over HTTPS?
|
|
Strong encryption
- TLS uses 128-bit encryption.
- Cannot control on client but can on server.
Message-driven applications
- HTTPS only provides encryption for channels (e.g. TCP).
- Applications sending messages over insecure transports (e.g. UDP,
Bluetooth) should implement cryptography.
Example
In establishing a secure connection, IE attempts to verify the
certificate. On failure, it displays this familiar popup.

About Encryption
Excerpted from Microsoft IIS 5.1 Documentation
Sensitive information transmitted across an unsecured network can potentially
be intercepted by a computer vandal. For this reason, if you plan to provide
users with access to Web sites that process sensitive financial or personal
information, you need to protect your network links with encryption.
Encryption is the process of scrambling information by applying a
mathematical function in such a way that it is extremely difficult for anyone
other than an intended recipient to retrieve the original information. Central
to this process is a mathematical value, called a key, which is used by
the function to scramble the information in a unique and complex way.
Your Web server uses essentially the same encryption process to secure
communication links with users. After establishing a secure link, a special session key is used by both your Web server and the user's Web browser to
both encrypt and decrypt information. For example, when an authenticated user
attempts to download a file from a Web site requiring a secure channel, your Web
server uses a session key to encrypt the file and related HTTP headers. After
receiving the encrypted file, the Web browser then uses a copy of the same
session key to recover the file.
This method of encryption, although secure, has an inherent drawback: During
the process of creating a secure link, a copy of the session key might be
transmitted across an unsecured network. This means that a computer vandal
intent on compromising the link need only intercept and steal the session key.
To safeguard against this possibility, however, your Web server implements an
additional method of encryption.
Your Web server's Secure Sockets Layer (SSL) security feature utilizes a
technique known as public key encryption to shield the session key from
interception during transmission. Public key encryption, which involves the use
of two additional keys, a private and a public key, works in
the following manner:
- The user's Web browser establishes a secure (https://) communication link
with your Web server.
- The user's Web browser and your server engage in negotiation to determine
the degree of encryption to use for securing communications.
- Your Web server sends the browser its public key.
- The Web browser encrypts information used in generating a session key with
the server's public key and sends it to the server.
- Using the private key, your server decrypts the message, generates a
session key, encrypts it with the public key, and sends it to the browser.
- Your Web server and the browser both use the session key to encrypt and
decrypt transmitted data.
Notice that the private key serves an important role in ensuring that your
communication link remains secure. You should take every reasonable precaution
to protect the private key from loss or theft. You can back up your certificate
by copying it to floppy disk and keeping it in a safe place. Likewise, if you
suspect that your private key has been compromised, notify your certification
authority, use the Web Server Certificate Wizard to create a new certificate
request, and then obtain a new server certificate.
A session key's strength is proportional to the number of binary
bits comprising the session key file. This means that session keys with a
greater number of bits have a greater degree of security, and are considerably
more difficult to forcibly decode.
When a user attempts to establish a secure communication channel with your
Web server, the user's browser must negotiate the strongest possible level of
encryption, or session key strength, that can be used to secure communications
over that channel. This means that both your Web server and the user's browser
must be equipped with compatible session key encryption and decryption
capabilities. For example, when you configure your Web server to require a
session key with a minimum 40-bit (default) encryption strength, a user
attempting to secure a connection must have a Web browser capable of processing
information with a 40-bit session key.
How to use makecert.exe to create a self-signed test certificate that can
be used with IIS for SSL
Problem: Special options must be specified with makecert.exe, to
create a self-signed certificate that can be used with IIS (Microsoft Internet
Information Server).
Note: Microsoft recommends to install and use the "Certificate Server"
to generate an SSL test certificate (Q216907), instead of using makecert.exe. But using makecert is
simpler.
Solution:
The following command can be used to create and import a self-signed SSL test
certificate:
makecert -r -pe -n "CN=www.yourserver.com" -b 01/01/2000 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12
To install this certificate in IIS 5.0, open the IIS "Web Site Properties",
"Directory Security", "Server Certificate...", "Assign an existing certificate"
and select the new certificate from the list.
Note: Older versions of makecert.exe do not support the "-pe" option,
which makes the private key exportable. If you have an old version of
makecert.exe, you can omit the "-pe" option, but then the certificate cannot be
exported including the private key.
(Visual Studio contains
makecert.exe (5.131) that supports the "-pe"
option. The .NET Framework SDK 1.0 of 2002-03-19 contains an old version of
makecert.exe that does not support the "-pe" option).
If the private key is exportable, you can export the certificate together
with the private key into a PFX (PKCS #12) file as described in
Q232136.
Note: SSL server certificates for IIS are stored in the "Personal"
("My") certificate store of the "computer account" ("localMachine"). The
"Certificates" snap-in of the Microsoft Management Console (mmc.exe) must be
used to manage these certificates. The normal certificate management window
(accessible via "Internet Properties" / "Content" / "Certificates" or via
"Control Panel" / "Users and Passwords" / "Advanced" / "Certificates") cannot be
used.
Note: To create a key with more than 512 bits, use the "-len"
parameter of makecert.exe.
Author: Christian
d'Heureuse (chdh@inventec.ch)
Exercise 0 - SSL
The following will install and test the use of SSL using self-signed
certificates.
- The makecert.exe utility is installed with .NET SDK.
-
Open a Command prompt window and enter:
makecert -r -pe -n "CN=localhost" -b 01/01/2000 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12
- To install this certificate in IIS 5.0:
- Start | Run | Control | Administration Tools | Internet
Information Services | Default Web Site Properties |
Directory Security | Server Certificate | Assign an existing
certificate... | Select the new certificate from the list
- To test that SSL is in use between the server and browser, enter in
the browser address bar:
- https://localhost/project/Welcome.xml
|
|
Servers
- Server security holes are attractive to hackers since all
servers of the same flavor may have the same weakness. Server holes are usually patched by the vendor but
require the updates to be applied. Microsoft's own servers were hacked because
they had failed to install the most recent updates/patches.
Server configuration is an administration
problem that varies from one server to another, setting promiscuous access
rights to files or directories can compromise the system. There are security scanners available that probe for known holes in server software,
since intruders also probe potential victims with the same scanners, its
advisable to check it yourself before someone else does. Popular scanners are:
COPS, TAMU, SATAN (from an IU CSCI dropout), and ISS.
- After careful configuration and security testing, the server may still be
vulnerable to the external disk attack. Simply booting up the server on a
disk gives complete access to the machine hardware. Linux can be installed on
a single disk along with NTFS drivers, booting a Windows machine
on Linux circumvents any of the careful file and directory configuration
restrictions. Lock the server away, unplug the drive, CD-ROM and any other
bootable device.
Hosts
- Securing a host is a continual exercise but begins with two tasks:
- Configure a firewall
- Download and install ZoneAlarm,
a free fire wall for personal use on Windows machines.
- Test firewall
- To probe for potential security problems of a host go to
grc.com for Shields UP! Run Test My
Shields.
- The official Windows security test is at
Microsoft.