Writing secure Code

UNIT III
Secure Coding Techniques:
Running with Least Privilege: Least Privilege in the Real World, Brief Overview of Access Control, Brief
Overview of Privileges, Brief Overview of Tokens, How Tokens, Privileges, SIDs, ACLs, and Processes Relate,
A Process for Determining Appropriate Privilege, Low-Privilege Service Accounts in Windows XP and
Windows .NET Server, Debugging Least-Privilege Issues.
Storing Secrets: Attack Methods, Sometimes You Don't Need to Store a Secret, Getting the Secret from the
User, Raising the Security Bar, An Idea: Using External Devices to Encrypt Secret Data.
 Secure Coding Techniques
Running with Least Privilege
• There exists in the field of security the notion of always performing tasks
with the least set of privileges required to perform those tasks.
• To cut a piece of plastic pipe, you could use a hacksaw or a chainsaw. Both
will do the job, but the chainsaw is overkill.
• If you get things wrong, the chainsaw is probably going to destroy the pipe.
• The hacksaw will do the job perfectly well.
• The same applies to executable processes—they should run with no more privilege
than is required to perform the task.
• Any serious software flaw, such as a buffer overrun, that can lead to security
issues will do less damage if the compromised software is running with few
privileges.
• Problems occur when users accidentally or unintentionally execute malicious
code (for example, Trojans in e-mail attachments or code injection through a
buffer overrun) that runs with the user's elevated capabilities.
• For example, the process created when a Trojan is launched inherits all the
capabilities of the caller. In addition, if the user is a member of the local
Administrators group, the executed code can potentially have full system
privileges and object access.
 Secure Coding Techniques
Least Privilege in the Real World
• You can bury your head in the sand, but the Internet is full of bad guys out to
get your users as your users employ applications treated by you, and many of
the attacks in the past would have tailed if the programs were not running as
elevated accounts Presently, two of the more popular kinds of attacks on the
Internet are viruses/Trojans and Web server defacements.
• I want to spend some time on each of these categories and explain how some
common attacks could have been mitigated if the users had run their
applications as plain users.
Viruses and Trojans
• Viruses and Trojans both include malicious code unintentionally executed by
users Let's look at some well-known malicious code; we will see how the code
would have been foiled if the user executing the code were not an
administrator.
 Secure Coding Techniques
Least Privilege in the Real World
• Back Orifice Hack Orifice is a tool, which when installed on a computer allows
a remote attacker to. among other things, restart the computer, execute
applications, and view file contents on the infected computer, all unbeknownst
to the user. On installation, Back Orifice attempts to write to the Windows
system directory and to a number of registry keys, including
HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft Windows CurrentVersion\Run. Only
administrators can perform either of these tasks. If the user were not an
administrator on the computer, Back Orifice would fail to install.
• SubSeven similar to Back orifice, SubSeven enables unauthorized attackers to
access your computer over the internet without your knowledge. To run, SubSeven
creates a copy of itsell in the Windows system directory, updates Win.ini and
System.ini, and modifies registry service keys located in HKEY_LOCAL_MACHINE
and HKEY_CLASSES_ROOT. Only administrators can perform these tasks. Once again,
if the user were not an administrator, SubSeven would fail.
 Secure Coding Techniques
Least Privilege in the Real World
• FunLove Virus The FunLove virus, also called W32.FunLove.4099 by Symantec, uses
a technique that was first used in the W32.Bolzano virus. When the virus is
executed, it grants users access to all files by modifying the kernel access
checking code on the infected computer. It does so by writing a file to the
system directory and patching the Windows NT kernel, Ntoskrnl.exe. Unless the
user is an administrator, FunLove cannot write to these files and fails.
• ILoveYou Virus Possibly the most famous of the viruses and Trojans, ILoveYou,
also called VBS.Loveletter or The Love Bug, propagates itself using Microsoft
Outlook. It operates by writing itself to the system directory and then
attempts to update portions of HKEY_LOCAL_MACHINE in the registry. Once again,
this malware will fail unless the user is an administrator
 Secure Coding Techniques
Web Server Defacements
• Web server defacing is a common pastime for script kiddies, especially defacing
high-profile Web sites.
• A buffer overrun in the Internet Printing Protocol(IPP) functionality included
in Microsoft Windows 2000 and exposed through Internet Information Services
(IIS) allowed such delinquents to attack many IIS servers.
• The real danger is the IPP handler, which is implemented as an Internet Server
Application Programming Interface (ISAPI) extension, running as the SYSTEM
account.
• If IPP were not running as the local system account, fewer Web sites would have
been defaced.
• The local system account has full control of the computer, including the
ability to write new Web pages.
 Secure Coding Techniques
Brief Overview of Access Control
• Microsoft Windows NT, Windows 2000, and Windows XP protect securable resources
from unauthorized access in employing discretionary access control, which is
implemented through discretionary access control lists (DACLs).
• DACLs, often abbreviated to ACLs, are a series of access control entries
(ACEs).
• Each ACE lists a Security ID (SID) which represents a user, a group, or a
computer, often referred to as principals—and contains information about the
principal and the operations that the principal can perform on the resource.
• Some principals might be granted read access, and others might have full
control of the object protected by the ACL.
 Secure Coding Techniques
Brief Overview of Privileges
• All Windows NT, Windows 2000. and Windows XP user accounts have privileges, or
rights, that allow or disallow certain privileged operations affecting an
entire computer rather than specific objects.
• Examples of such privileges include the ability to log on to a computer, to
debug programs belonging to other users, to change the system time, and so on.
• Some privileges are extremely potent; the most potent are defined in Table 5-1.
 Secure Coding Techniques
SeBackupPrivilege Issues
• An account having the Backup Files And Directories privilege can read files the
account would normally not have access to.
• For example, if a user named Blake wants to back up a file and the ACL on the
file would normally deny Blake access, the fact that he has this privilege will
allow him to read the file. A backup program reads files by setting the
FILE_FLAG_BACKUP_SEMANTICS flag when calling CreateFile.
• Try for yourself by performing these steps:
• Log on as an account that has the backup privilege—for example, a local
administrator or a backup operator.
• Create a small text file, named Test.txt, that contains some junk text.
• Using the ACL editor tool, add a deny ACE to the file to deny yourself access.
For example, if your account name is Blake, add a Blake (Deny All) ACE.
• Compile and run the code that follows this list. Refer to MSDN at
msdn.microsoft.com or the Platform SDK for details about the security-related
functions.
 Secure Coding Techniques
SeDebugPrivilege Issues
• An account having the Debug Programs privilege can attach to any process and
view and adjust its memory. Hence, if an application has.
• some secret to protect, any user having this privilege and enough know-how can
access the secret data by attaching a debugger to the process.
• You can find a good example of the risk "Storing Secrets."
• A tool from nCipher (www.77cipher.com) can read the private key used for
SSL/TLS communications by groveling through a process's memory, but only if the
attacker has this privilege.
• The Debug Programs privilege also allows the caller to terminate any process on
the computer through use of the TerminateProcess function call.
• In essence, a nonadministrator with this privilege can shut down a computer by
terminating the Local Security Authority (LSA), Lsass.exe.
• Finally, the most insidious possibility: an attacker with debug privileges can
execute code in any running process by using the CreateRemoteThread function.
• This is how the LSADUMP2 tool, available at razor.bindview.com/tools, works.
LSADUMP2 allows the user having this privilege to view secret data stored in
the LSA by injecting a new thread into Lsass.exe to run code that reads private
data after it has been decrypted by the LSA.
 Secure Coding Techniques
SeTcbPrivilege Issues
• An account having the Act As Part Of The Operating System privilege essentially
behaves as a highly trusted system component.
• The privilege is also referred to as the Trusted Computing Base (TCB)
privilege.
• TCB is the most trusted and hence most dangerous privilege in Windows.
• Because of this, the only account that has this privilege by default is SYSTEM.
SeAssignPrimaryTokenPrivilege and SelncreaseQuotaPrivilege Issues
• An account having the Replace A Process Level Token and Increase Quotas
privileges can access a process token and then create a new process on behalf
of the user of the other process.
• This can potentially lead to spoofing or privilege elevation attacks.
 Secure Coding Techniques
Brief Overview of Tokens
• When a user logs on to a computer running Windows NT, Windows 2000, or Windows
XP and the account is authenticated, a data structure called a token is created
for the user by the operating system, and this token is applied to every
process and thread within each process that the user starts up.
• The token contains, among other things, the user's SID, one SID for each group
the user belongs to, and a list of privileges held by the user.
• Essentially, it is the token that determines what capabilities a user has on
the computer.
• Starting with Windows 2000. the token can also contain information about which
SIDs and privileges are explicitly removed or disabled.
• Such a token is called a restricted token.
 Secure Coding Techniques
How Tokens, Privileges, SIDs, ACLs, and Processes Relate
• All processes in Window NT. Windows 2000. and Windows XP run with some
identity: in other words, a token is associated with the process.
• Normally, the process runs as the identity of the user that started the
application.
• However, applications can be started as other user accounts through use of the
CreateProcessAsVser function by a user who has the appropriate privileges.
• Typically, the process that calls the CreateProcessAsUser function must have
the SeAssignPrimaryTokenPrivilege and SelncreaseQuotaPrivilege privileges.
• However, if the token passed as the first argument is a restricted version of
the caller's primary token, the SeAsslgnPrtmafyTbkenPrtvilege privilege is not
required.
• Another type of process, a service, runs with the identity defined in the
Service Control Manager (SCM).
• By default, many services run as the local system account, but this can be
configured to run as another account by entering the name and password for the
account into the SCM.
 Secure Coding Techniques
A Process for Determining Appropriate Privilege
• If your application requires that you run as an administrator, you need to
vouch for each SID and privilege in the administrator's token. If you cannot,
you should consider removing some of the token entries.
• Here's a process you can use to help determine, based on the requirements of
your application, whether each SID and privilege should be in a token:
• Find out each resource the application uses.
• Find out each privileged API the application calls.
• Evaluate the account under which the application is required to run.
• Ascertain the SIDs and privileges in the token.
• Determine which SIDs and privileges are required to perform the application
tasks.
• Adjust the token to meet the requirements in the previous step.
 Secure Coding Techniques
A Process for Determining Appropriate Privilege
Step 1: Find Resources Used by the Application
• The first step is draw up a list of all the resources used by the application:
files, registry keys. Active Directory data, named pipes, sockets, and so on.
• You also need to establish what kind of access is required for each of these
resources.
• For example, a sample Windows application that I'll use to illustrate the
privilege- determining process utilizes the resources described in Table 5-2.
 Secure Coding Techniques
A Process for Determining Appropriate Privilege
Step 2: Find Privileged APIs Used by the Application
• Analyze which, if any. privileged APIs are used by the application. Examples
include those in Table 5-3.
 Secure Coding Techniques
A Process for Determining Appropriate Privilege
 Secure Coding Techniques
A Process for Determining Appropriate Privilege
Step 3: Which Account Is Required?
• Write down the account under which you require the application to run.
• For example, determine whether your application requires an administrator
account to run or whether your service requires the local system account to
run.
• For our sample Windows application, development was lazy and determined that
the application would work only if the user were an administrator.
• The testers were equally lazy and never tested the application under anything
but an administrator account.
• The designers were equally to blame—they listened to development and the
testers!
 Secure Coding Techniques
A Process for Determining Appropriate Privilege
Step 4: Get the Token Contents
• You can do this either by logging on as the account you want to test or by using
the RunAs command to start a new command shell.
• For example, if you require your application to run as an administrator, you could
enter the following at the command line: RunAs /user :MyMachine\Admini strator
cmd.exe
• This would start a command shell as the administrator—assuming you know the
administrator password—and any application started in that shell would also run as
an administrator.
• If you are an administrator and you want to run a shell as SYSTEM, you can use the
task scheduler service command to schedule a task one minute in the future, for
example, assuming the current time is 5:01 P.M. (17:01 using the 24-hour clock),
the following will start a command shell no more than one minute in the future: At
17:02 /INTERACTIVE "cmd.exe"
• The- newly created command shell runs in the local system account context.
• Now that you are running as the account you are interested in. run the following
test code, named MyTaken.cpp. from within the context of the account you want to
interrogate.
 Secure Coding Techniques
A Process for Determining Appropriate Privilege
Step 5: Are All the SIDs and Privileges Required?
• Here's the fun part: have members from the design, development, and test teams
analyze each SID and privilege in the token and determine whether each is required.
• This task is performed by comparing the list of resources and used APIs found in
steps 1 and 2 against the contents of the token from step 4.
• If SIDs or privileges in the token do not have corresponding requirements, you
should consider removing them.
• In our sample application, we find that the application is performing ACL checks
only, not privilege checks, but the list of unused privileges is huge!
• If your application has a vulnerability that allows an attacker's code to execute,
it will do so with all these privileges.
• Of the privileges listed, the debug privilege is probably the most dangerous, for
all the reasons.
 Secure Coding Techniques
A Process for Determining Appropriate Privilege
Step 6: Adjust the Token
• The final Step is to reduce the token capabilities, which you can do in two ways:
• Allow less-privileged accounts to run your application.
• Use restricted tokens.
• Let's look at each in detail.
Allow Less-Privileged Accounts to Run Your Application
• You can allow less-privileged accounts to run your application but not allow them
to perform certain features. For example, your application might allow
• users to perform 95 percent of the tasks in the product but not allow them to, say,
perform backups.
• One more aspect of running with least privilege exists: sometimes applications are
poorly designed and require elevated privileges when they are not really needed.
Often, the only way to rectify this sad state of affairs is to rearchitect the
application.
 Secure Coding Techniques
A Process for Determining Appropriate Privilege
Use Restricted Tokens
• A new feature added to Windows 2000 and later is the ability to take a user token
and "dumb it down," or restrict its capabilities.
• A restricted token is a primary or impersonation token that the
CreateRestrictedToken function has modified.
• A process or thread running in the security context of a restricted token is
restricted in its ability to access securable objects or perform privileged
operations.
• You can perform three operations on a token with this function to restrict the
token.
• Removing privileges from the token
• Specifying a list of restricting SIDs
• Applying the deny-only attribute to SIDs
 Secure Coding Techniques
Low-Privilege Service Accounts in Windows XP and Windows .NET Server
• Traditionally, Windows services have had the choice of running under either the
local system security context or under some arbitrary user account.
• Creating user accounts for each service is unwieldy at best.
• Because of this, nearly all local services are configured to run as SYSTEM.
• The problem with this is that the local system account is highly privileged—TCB,
SYSTEM SID, and Local Administrators SID, among others—and breaking into the
service is often an easy way to achieve a privilege elevation attack.
• Many services don't need an elevated privilege level; hence the need for a lower
privilege-level security context available on all systems.
• Windows XP introduces two new service accounts:
• The local service account (NT AUTHORITYXLocalService)
• The network service account (NT AUTHORITYXNetworkService)
• The local service account has minimal privileges on the computer and acts as the
anonymous user account when accessing network-based resources.
• The network service account also has minimal privileges on the computer; however,
it acts as the computer account when accessing network-based resources.
 Secure Coding Techniques
Low-Privilege Service Accounts in Windows XP and Windows .NET Server
• For example, if your service runs on a computer named BlakeLaptop as the local
Service account and accesses, say, a file on a remote computer, you’ll see the
anonymous user account (not to be confused with the guest account) attempt to
access the resource.
• In many cases, unauthenticated access (that is, anonymous access) is disallowed,
and the request for the network-based file will fail. If your service runs as the
network service account on BlakeLaptop and accesses the same file on the same
remote computer, you'll see an account named BLAKELAPTOP$ attempt to access the
file.
 Secure Coding Techniques
Debugging Least-Privilege Issues
• You might be wondering why I'm adding a debugging section to a book about good
security design and coding practices.
• Developers and testers often balk at running their applications with least
privilege because working out why an application fails can be difficult. This
section covers some of the best ways to debug applications that fail to operate
correctly when running as a lowerprivilege account, such as a general user and not
as an administrator.
 Secure Coding Techniques
Debugging Least-Privilege Issues
Why Applications Fail as a Normal User
• Many applications designed for Windows 95, Windows 98 and Windows Me do not take
into consideration that they might run in a more secure environment such as Windows
NT, Windows 2000, or Windows XP These applications fail because of privilege
failures, NTFS ACL failures, and registry ACL failures.
• Also,applications might fail in various ways and give no indication that the
failure stems from a security error, because they were never tested on a secure
platform in the first place.
• For example, a popular word processor we tested yielded an Unable To Load error
when the application ran as a normal user but worked flawlessly as an
administrator.
• Further investigation showed that the application failed because it was denied
access to write to a registry key.
• Most disconcerting was the Out Of Memory error we saw. This led us to spend hours
debugging the wrong stuff until finally we contacted the vendor, who informed us
that if all error-causing possibilities are exhausted, the problem must be a lack
of memory! This was not the case—the error was an Access Denied error while
attempting to write to the c: Program Files directory.
 Secure Coding Techniques
Debugging Least-Privilege Issues
• How to Determine Why Applications Fail
• Three tools are useful in determining why applications fail for security reasons:
• The Windows Event Viewer
• RegMon (from www.sysinternals.com)
• FileMon (from www.sysinternals.com)
• The Windows Event Viewer: The Windows Event Viewer will display security errors if
the developer or tester elects to audit for specific security categories. It is
recommended that you audit for failed and successful use of privileges. This will
help determine whether the application has attempted to use a privilege available
only to higher-privileged accounts. For example, it is not unreasonable to expect a
backup program to require backup privileges, which are not available to most users.
• RegMon and FileMon Main failures occur because ACL checks failing in the registry
or the file system. These failures can be determined by using RegMon and FileMon,
two superb tools from WWW.iysilUernols.com. Both these tools display ACCDENIED
errors when the process attempts to use the registry or the file system in an
inappropriate manner for that user account.
 Secure Coding Techniques
Attack Methods
• An attacker can access private information held in software in many ways, some
obvious and others not so obvious, depending on how the data is stored and how it's
protected.
• One method is simply to read the unencrypted data from the source, such as the
registry or a file.
• You can mitigate this method by using encryption, but where do you store the
encryption key? In the registry? How do you store and protect that key? It's a
difficult problem to solve.
• Let's imagine you decide to store the data by using some new, previously
undiscovered, revolutionary way.
• For example, your application is well written and builds up a secret from multiple
locations, hashing them together to yield the final secret.
• At some point, your application requires the private data.
• All an attacker need do is hook up a debugger to your process using the secret, set
a breakpoint at the location where your code gathers the information together, and
then read the data in the debugger.
 Secure Coding Techniques
Attack Methods
• Now the attacker has the data. One way to mitigate this threat on Windows NT.
Windows 2000, and Windows XP is to limit which accounts have the Debug Programs
privilege—referred to as SeDebugPhvilege or SE_DEBUG_NAME in the Microsoft Platform
SDK—because this privilege is required to debug a process running under a different
account.
• By default, only administrators have this privilege.
• Another danger is an asynchronous event, such as the memory holding the secret
becoming paged to the page file.
• If an attacker has access to the Pagefile.sys file, he might be able to access set
ret data.
• If you have the secret data held in plaintext in the application's memory, it too
will be written to the disk.
• Remember that the bad guys are always administrators on their own machines They can
install your software on those machines and crack it there.
 Secure Coding Techniques
Sometimes You Don't Need to Store a Secret
• It you store a secret for the purpose of verifying that another entity also knows
the secret, you probably don't need to store the secret itself.
• Instead, you can store a verifier, which often takes the form of a cryptographic
hash of the secret.
• For example, if an application needs to verify that a user knows a password, you
can compare the hash of the secret entered by the user with the hash of the secret
stored by the application.
• In this case, the secret is not stored by the application—only the hash is stored.
• This presents less risk because even if the system is compromised, the secret
itself cannot be retrieved—only the hash can be accessed.
 Secure Coding Techniques
Getting the Secret from the User
• The most secure way of storing and protecting secrets is to get the secret from a
user each time the secret is used.
• In other words, if you need a password from the user, get it from the user, use it.
and discard it.
• However, using secret data in this way can often become infeasible for most users.
• The more items of information you make a user remember, the greater the likelihood
that the user will employ the same password over and over, reducing the security
and usability of the system.
 Secure Coding Techniques
Raising the Security Bar
• This section focuses on the different ways of storing secret data and describes the
effort required by an attacker to read or to modify the data (data-tampering
threat!
• Storing the Data in a File on a FAT File System
• In this example, the file is stored on an unprotected disk drive.
• All the attacker needs to do is read the file, either by using file access or
possibly through a Web server.
• This is very weak indeed—if the attacker can access the computer locally or
remotely, she can probably read the file.
• Using an Embedded Key and XOR to Encode the Data
• The details in this case are the same as in the previous scenario, but a key
embedded in the application that reads the file is used to XOR the data.
• If the attacker can read the file, he can break the XOR in a matter of minutes,
especially f he knows the file contains text.
• It's even worse if the attacker knows a portion of the text—for example, a
header, such as the header in a Word file or a GIF file.
• All the attacker need do is XOR the known text with the encoded text, and he
will determine the key or at least have enough information to determine the
key.
 Secure Coding Techniques
• Using an Embedded Key and 3DES to Encrypt the Data
• Same details as In the previous scenario, hut a 3DES (Triple-DES) key is
embedded In the application.
• This is also trivial to break.
• Using 3DES to Encrypt the Data and Storing a Password in the Registry
• Same as in the previous scenario, hut the key used to encrypt the data is held
in the registry rather than embedded in the application.
• If the attacker can read the registry, she can read the encrypted data. Also
note that if the attacker can read the file and you're using a weak password as
the key, the attacker can perform a password-guessing attack.
• Using 3DES to Encrypt the Data and Storing a Strong Key in the Registry
• Same as the previous scenario, but now the attacker has a much harder time
unless he can read the key from the registry.
• A brute-force attack is required, which might take a long time.
• However, if the attacker can read the registry, he can break the file.
 Secure Coding Techniques
• Using 3DES to Encrypt the Data, Storing a Strong Key in the Registry, and ACLing
the File and the Registry Key
• In this case, if the ACLs are good—for example, the ACL contains only the
Administrators (Read, Write) ACE—the attacker cannot read the key or the file
if the attacker doesn't have administrator privileges.
• However, if a vulnerability in the system gives the attacker administrator
privileges, he can read the data.
• Ultimately, you have to consider using alternative ways of storing keys,
preferably keys not held on the computer.
• You can do this in numerous ways, including using special hardware from
companies such as nCipher(www.ncipher.com). Another method is described next.
 Secure Coding Techniques
An Idea: Using External Devices to Encrypt Secret Data
• Many people use handheld devices, such as the Windows CE-powered Microsoft Pocket
PC, to keep track of day-to-day events, take notes, play games, browse the
Internet, and read e-mail.
• These devices are also excellent development platforms because they include a good
range of Windows-based application programming interfaces.
• One such interface is CryptoAPI. Windows CE 3-powered devices, such as the Compaq
iPAQ 3600 series, the CASIO EM-500.
• What if I can use such a device to store a cryptographic key and I offload the
cryptographic work to the device rather than the host PC?
• I set about writing a simple Pocket PC-based tool named PPCKey. Let's look at a
sample scenario for PPCKey.
 Secure Coding Techniques
A Sample Scenario Using PPCKey
• We arc all aware of the great time saving aspects of the Remember My Password check
box on many login dialog boxes.
• While this is certainly a great usability feature, it's also a potential security
hole because the password is either stored in the clear on the computer or
encrypted with a key that's held on the computer.
• On all operating systems, including windows, it is difficult to protect the
encryption key.
• In fact, many applications hard-code the key such that an attacker can gain any
password.
• And once the key is discovered, the attacker can unlock all passwords encrypted
with that key.
• PPCKey gels around this issue by storing a secret cryptographic key on a Pocket PC
and then allowing the Pocket PC to encrypt and decrypt sensitive information based
on that key
 Secure Coding Techniques
A Sample Scenario Using PPCKey
• Here's a scenario that shows how the PPCKey tool works:
• A key-generation program executed on the Pocket PC derives a strong
cryptographic key seed and writes it to the registry on the Pocket PC. This is
performed once The key is 12<S bits long and is derived by calling
CryptGenRandom.
• While using a Windows-based application, a user is prompted to enter her
credentials, which comprise her username and her password.
• Once the user has entered her credentials, she selects the Remember My Password
option.
• The application takes the password from the dialog box and calls the PPCKey
API. implemented as a C++ class, to encrypt the data.
• The client-side PPCKey C++ class takes the password and sends it to the Pocket
PC by using the Windows CE Remote API (RAPI) functionality.
• The PPCKey DLL on the Pocket PC encrypts the password with a strong
cryptographic key—that is. one composed of a random stream of bits—held on the
device and returns the encrypted blob to the application.
 Secure Coding Techniques
A Sample Scenario Using PPCKey
• Here's a scenario that shows how the PPCKey tool works:
• The Windows based application persists the encrypted blob in, for example, the
registry
• At a future date, the user loads the Windows-based application, but rather than
presenting the user with a credentials dialog box. The application takes the-
encrypted blob from the registry and calls the PPCKey C++ class to decrypt the
data.
• The client-side PPCkev C++ class pusses the blob to the Pocket PC-based PPCKey DLL
by using RAPI.
• The Pocket PC-based PPCkey DLL decrypts the blob with the key held on the device
and returns the password to the application.
• The application uses the password and then discards the password.
 Secure Coding Techniques
A PPCKey Threat Model
• This section outlines a threat model for the PPCKey application. The threats to
PPCKey include the following:
• Attacker has access to both the Pocket PC and the Windows client
• Attacker guesses key by watching the order of registry writes on the Pocket PC
• Attacker performs a brute-force attack on ciphertext held on the PC
• Attacker determines that two applications have the same password
• Attacker looks for plaintext in memory
• Attacker guesses key
• Attacker enumerates the registry and tries all key values
 Writing secure Code
UNIT IV
Network-Based Application Considerations
Socket Security: Avoiding Server Hijacking, Choosing Server Interfaces, Accepting Connections, Writing
Firewall-Friendly Applications, Spoofing and Host-Based and Port- Based Trust.
Securing RPC, ActiveX Controls, and DCOM: Secure RPC Best Practices, Secure DCOM Best Practices,
Secure ActiveX Best Practices.
Protecting Against Denial-of-Service Attacks: Application Failure Attacks, CPU Starvation Attacks, Memory
Starvation Attacks, Resource Starvation Attacks, Network Bandwidth Attacks.
UNIT V
Writing secure Code
Securing Web-Based Services
Never Trust User Input: User Input Vulnerabilities, User Input Remedies. Web-Specific
Canonicalization Bugs: 7-Bit and 8-Bit ASCII, Hexadecimal Escape Codes, UTF-8 Variable-Width
Encoding, UCS-2 Unicode Encoding, Double Encoding, HTML Escape Codes, Web-Based
Canonicalization Remedies. Other Web-Based Security Topics: HTTP Trust Issues, ISAPI Applications
and Filters, Don't Store Secrets in Web Pages.
Testing Secure Applications: The Role of the Security Tester, Security Testing Is Different, Building the
Security Test Plan, Testing Clients with Rogue Servers, Should a User See or Modify That Data? Testing
with Security Templates, Test Code Should Be of Great Quality, Test the End-to-End Solution, Slightly
Off-Topic: Code Reviews.