Send requests/responses out of order

The client/server might not maintain proper state, might allow certain validation to be bypassed, or might crash the client/server.

Modify a packet’s contents to slightly different values. Example: Change the price value from 100 to 1

Abuse the logic of the client/server with valid datatypes.

Remove fields from the network request/response

Crash the parser or bypass any checks performed on the field.

Modify the query string values, POST data, and cookie values

Obtain or modify data not normally accessible.

Send invalid, illegal, or malformed for the values of the fields in the request/response

Crash the parser.

Save HTML forms to another site and submit the form as a different user from the one who requested it

Cross-site request forgery (CSRF) attack.

Check for features that trust a connection based on the domain from which the connection originates

Trust should not be elevated based on a domain name gained through a DNS reverse lookup (it can be spoofed).

Hand-craft SMTP messages

To, From, Subject, headers, body, and so forth can all be spoofed.

Modify HTTP Referer

Some features erroneously use this to ensure links originate from specific places.

Modify MAC address

Some features mistakenly believe that MAC addresses are unique and cannot be spoofed.

Spoofing IP address

Like the MAC address, a machine’s IP can also be spoofed, which is commonly used in DDoS attacks.

Some text<CR/LF>Text on new line

Use a carriage return and linefeed (<CR/LF>) to inject a new line, which can alter the dialog box layout.

Some text<TAB><TAB><TAB><TAB>More text

Use tab characters (<TAB>) to inject whitespace to cause the text to wrap to the next line in a dialog box.

Some text More text

Use a lot of spaces to cause the text to wrap to a new line in a dialog box.

Some text<NULL>Text is truncated

Use a NULL to truncate the line displayed.

C:goodfile.txt<TAB><TAB><TAB><TAB>.exe

Use tab characters in the filename to cause part of the filename to wrap out of the viewable text area.

C:goodfile.txt .exe

Use spaces in the filename to cause part of the filename to wrap out of the viewable text area.

http://www.goodsite.com@

www.badsite.com

Some applications allow the user name and password to be specified as part of the URL. Use the user name to attempt to spoof the name of the server.

http://www.goodsite.com/good.txt%00bad.exe

Use an encoded null character (%00) to truncate the name of a file.

http://www.goodsite.com/good.txt%0D%0Abad.exe

Use an encoded CR/LF (%0D%0A) to inject a new line.

Monitor data sent across the network

An attacker can potentially monitor and even tamper with data that is sent over a network. Use tools, such as Ethereal, to monitor the network traffic. Sensitive data should be encrypted, such as by using SSL.

Monitor data stored in files

Every file the application uses can potentially disclose information, including the application’s program files, any temporary files the application might create, and the output files that are generated by the application.

Monitor the information stored in memory

Information stored in memory can potentially be accessible to other users in ways you wouldn’t expect. For instance, the system could potentially dump the memory to a page file or a file used when the system hibernates.

Look for “secrets”

Any binary files that contain secrets, such as keys, passwords, and so forth, that the application uses to encrypt or protect data should never be stored in the file because an attacker can reverse engineer the file and extract them.

Look for credentials stored in clear text

Credentials, passwords, database connection strings, and so forth should never be stored in clear text, especially if they aren’t protected with access control.

Look at the contents of binary files for sensitive data

Files can contain more information than might be obvious. Use tools, such as Strings or a binary editor, to look at the data stored in a binary file.

Look for internal server names

Sometimes internal server names are considered sensitive information because an attacker can use those names to aid them in attacking your internal network.

Look for file path disclosures returned by a Web application

A Web application should disclose information about the Web server itself. Look for places, especially error conditions, where file paths of the server are disclosed.

Exercise error conditions

Often, error conditions can reveal useful information to an attacker. Exercise all the error conditions that are possible and observe the results.

Look for more information returned than is needed

Even simple information, such as whether a logon was unsuccessful, can be a security vulnerability that an attacker can use against your system. Question whether the information returned to a user is too much and too revealing.

Look for places where data is obfuscated

Obfuscated data, including encoded data, does not protect sensitive information. For instance, using certain encodings, such as base64 or hexadecimal, might not make a password understandable at first glance; however, after an attacker figures out which encoding was used, the attacker can easily determine the unencoded password.

Look for sensitive data that is part of the URL

Even if the connection uses SSL, the URL is still readable in clear text. Also, the HTTP Referer can disclose sensitive information.

Make sure sensitive data the application uses cannot be guessed easily

If the data can be guessed easily, it can’t be protected from an attacker. For example, if a Web application uses consecutive numbers for the session ID, an attacker will easily be able to guess someone else’s valid session ID.

<BO>:folderfile.txt

Attempt to overflow the drive letter of a file path.

C:<BO>file.txt

Attempt to overflow the name of a folder.

C:folder<BO>.txt

Attempt to overflow the filename.

C:folderfile.<BO>

Attempt to overflow the extension.

<BO>://www.server.com/file.txt

Attempt to overflow the protocol portion of a URL.

http://<BO>/file.txt

Attempt to overflow the server name.

http://www.<BO>.com/file.txt

Attempt to overflow portions of the server name.

http://server/<BO>.txt

Attempt to overflow the filename.

http://server /file.<BO>

Attempt to overflow the extension.

http://server/file.asp?<BO>

Attempt to overflow the query string.

http://server/file.asp?<BO>=value

Attempt to overflow part of the query string parameter names.

http://server /file.asp?name=<BO>

Attempt to overflow the query string parameter values.

String

Alter the length preceding the string by making it small.

x7fxffxffxffString

Alter the length preceding a string by making it large.

Remove the null terminator

Hope the copy routine will keep copying.

Run code analysis tools like lint

Many code-based and runtime tools can help catch buffer flow errors in code.

Fuzz

Fuzzing the input data can help identify issues.

MAX input length

Identify the expected max length of a value.

(MAX – 1) input length

Try one less than the expected max length of a value.

(MAX + 1) input length

Try one more than the expected max length of a value.

(MAX + n) input length

Keep incrementing the number of max bytes expected one at a time until application error.

Try string input > 2^n long

Sometimes allocations are 2^n.

Try numeric input > 2^15, 2^16, 2^31, 2^32 in value

Doing so can help spot integer overflows.

%n%n%n... %n

A long string of %n sequences will alter the stack.

%s%s%s... %s

Some implementations don’t support %n.

%d and %x

Other common identifiers that could lead to problems.

Review functions

By examining use of functions in Table 9-1 of Chapter 9, you can spot these attacks.

<SCRIPT>alert()</SCRIPT>

Standard script block.

"><SCRIPT>alert()</SCRIPT>

Close attribute and tag, and then start a script block.

'><SCRIPT>alert()</SCRIPT>

Close attribute and tag, and then start a script block.

</SCRIPT><SCRIPT>alert()</SCRIPT>

Close current script block, and then start a new script block.

javascript:alert()

Use this to execute script where a URL can be specified.

vbscript:MsgBox()

Use this to execute script where a URL can be specified.

" onclick=javascript:alert() x="

Inject script by inserting an attribute.

" style="font-family:
  expression(alert())" x="

Inject script by inserting an attribute, and using the expression method.

+ADw-SCRIPT+AD4-
  alert();
+ADw-/SCRIPT+AD4-

UTF-7 encoding of the script tag.

<INPUT
  name="txtInput1"
  type="text"
  value="SomeValue"
  style="font-family:
e/**/xpression(alert('Hi!'))"
>

Uses C-style comments in the expression method to trick parsers.

Injecting CR/LF

Injecting CR/LF is a common technique used to cause a HTTP content splitting attacks. If the CR/LF can be injected into values that could control HTTP headers in the server’s response, a splitting attack could lead to script injection.

Use XML that isn’t well formed.

Crash the parser.

<!ENTITY % xx '&#x25;zz;'>
<!ENTITY % zz '&#x25;xx;'>
%xx;

Infinite entity reference loop. The last line of this XML causes %xx to become %zz; and then %zz becomes %xx. Now %xx should be converted again. As you can see, the entity conversion is now in an infinite loop.

<?xml version="1.0"
  encoding="utf-8"?>
<!DOCTYPE something [
  <!ENTITY x0 "Developers!">
  <!ENTITY x1 "&x0;&x0;">
  <!ENTITY x2 "&x1;&x1;">
  <!ENTITY x3 "&x2;&x2;">
  <!ENTITY x4 "&x3;&x3;">
  ...
  <!ENTITY x100 "&x99;&x99;">
]>

The preceding XML first replaces “&x100;” with “&x99;&x99;” which is then replaced with “&x98;&x98;&x98;&x98”. This replacement chain would continue until the replacement string eventually becomes the string “Developers!” repeated 2^100 times; also known as a XML bomb.

<?xml version="1.0"
  encoding="UTF-8"?>
<!DOCTYPE myTest [
  <!ELEMENT secTest ANY>
  <!ENTITY xxe SYSTEM
    "c:/boot.ini">
]>
<secTest>&xxe;</secTest>

XML external (XXE) entity attack. If you are testing an application that takes XML input, verify that you cannot gain access to files normally not accessible by using XML similar to c:oot.ini.

User1</USER>
<USER role="admin">User2

XML injection.

x')] | //*| //*[contains(name,'y

XPath/XQuery injection.

<unluckyNumbers
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:enc="http://www.w3.org/2001/12/soap-
encoding"
  enc:arrayType="xs:int[500000]" >
  <number>4</number>
  ...
  <number>42</number>
</unluckyNumbers>

SOAP array DoS. Some servers allocate memory to prepare for the array following the array size specification, thus allowing for a potential DoS where the attacker specifies a large size that results in the server consuming large amounts of memory.

Verify DTDs aren’t used in SOAP 1.1 message

DTDs can be used to build strings dynamically on the victim’s machine and consumer large amounts of memory. The SOAP 1.1 specification states that a SOAP message must not contain a DTD.

http://server/test.asmx/method-name?param1=val1&param2=val2

SOAP CSRF attack using GET.

<FORM
  name="myForm"
  action=
    "http://server/test.asmx/method-name"
  method="POST"
>
<INPUT
  type="hidden"
  name="param1"
  value="val1">
<INPUT
  type="hidden"
  name="param2"
  value="val2">
<INPUT type="submit">
</FORM>

SOAP CSRF attack using POST.

%41

Hexadecimal encoding of a character (%41 = A).

%C1%81

Overlong UTF-8 encoding of a character (%C1%81 = A).

%2541

Double encoding of a character (%25 = %).

&gt;

&#65;

HTML encoding of a character

(&gt; = >; &#65; = A).

&#x41;

HTML hex encoding of a character (&#x41; = A).

&#0065;

HTML encoding of a character using padding (&#0065; = A).

<input
  type=text
  value=""
  style=
"left:expressio?(
document.bgColor='black')"
>

The ? is the Latin capital N U+FF2E, which IE will best fit the map into scriptable code.

C:folder..secret.password.txt

Directory traversal.

C:folder/secret.txt

Using a forward slash (/) instead of a backslash ().

Root or /Root

Using a leading forward slash (/) or backslash () to access the root.

http://server/folder%u002Ffile.txt

Using UCS-2 encoding of a character (%u002F = /).

\.C:windows otepad.exe

\?C:windows otepad.exe

\machineC$windows otepad.exe

\<ip>C$windows otepad.exe

\localhostC$windows otepad.exe

\127.0.0.1C$windows otepad.exe

Different ways to represent a local file.

%windir% otepad.exe

Using environment variables to represent a path.

C:windows otepad.exe.

Trailing period can still access a file.

C:windows otepad(space)

Trailing space can still represent a file.

C:Progra~1longfi~1.txt

Short version of the long filename for C:Program Fileslongfilename.txt.

file.txt:$data file.txt::$data file.txt::$default

Using alternative NTFS file system file streams.

http://3232235521

Use the decimal form of an IP address to create a dotless address that can be used to trick some applications that attempt to detect zones, such as Internet versus intranet.

NULL DACL

If an object has a NULL DACL (empty permissions), this is a must fix. Having a NULL DACL means that anyone can access the object.

Weak DACL

Granting permissions to large groups, such as Everyone, Guest, Authenticated Users, Users, Network Service, and World, can be granting too much access to a resource that should be more protected.

Granting too much permission

If a user or group shouldn’t be able to delete a file, don’t grant that permission. Restrict the permissions on a securable object to only those that are actually needed.

Look for multistage elevation of privilege attacks

Attackers often can chain multiple weaknesses together to gain a higher access level. For instance, it might not be possible for a user to go straight to an administrator account. However, the user could elevate to Network Service, and then to Administrator.

Use tools to detect weak permissions

Tools such as AccessEnum from SysInternals can easily indicate weak permissions on files and the registry.

AUX, COM1, COM2, COM3, COM4, LPT1, LPT2, LPT3, LPT4, PRN, CLOCK$, NUL

Sample DOS device names.

COM1:othertext, filename.COM1, COM1.ext, C:foldercom1file.txt

Additional ways to represent DOS device names.

C:folder............................file.txt

Look for characters that are being filtered, and then provide input that contains many characters that are filtered out.

Send lots of data to the application

The system might react differently depending on the amount of data used. Send lots of data to a feature, starting with a reasonable amount and gradually increasing the amount of data over time to see what happens.

Repeat same actions over and over

While repeating the same action over and over in an application, monitor for excessive CPU utilization, memory consumption, and any other resource leaks.

Change expected data types

If the application is expecting a numerical value, use alphabetic characters instead. Ideally, the application should handle cases when invalid data is passed into the application, especially if the attacker controls the data.

Fail to close any connections

Attempt to consume all of the connections that the server can handle to prevent new ones from being handled.

Exercise all error code paths

Check to see whether error codes release the appropriate resources.

Look for functions that incur heavy resource penalties

Functions, such as those used for encryption and decryption, can be very expensive. Look for these type of functions and see if a malicious user can remotely cause these functions to get called.

Look for APTCA assemblies

Any assembly that is marked with the AllowPartiallyTrustedCallers attribute (APTCA) can be called by partially trusted code, which can lead to luring attacks.

Look for unsafe code blocks, PInvokes of Win32 APIs, and marshaling of data

Managed code can call into unmanaged (native) code, which could lead to certain security problems. Search the code for “unsafe” or check whether the assembly was compiled using the /unsafe compiler option.

Look for asserts

If the code does an assert, especially if the assembly can be called from partially trusted code, make sure untrusted callers cannot call into the method.

Look for link demands

Look for all places that do a link demand and make sure they cannot be bypassed, such as by casting to an interface.

Look for sensitive data in the assembly

Microsoft .NET Framework assemblies can easily be decompiled, so be sure the source doesn’t contain any secrets or backdoors.

Search code for SqlCommand, etc.

Several keywords can be used to form SQL queries. If a SQL query is ever constructed using user-supplied data, look for SQL injection. It is better if parameterized queries are used instead of dynamic queries.

Search store procedures for EXEC, EXECUTE, sp_execute

If a stored procedure uses EXEC, EXECUTE, and sp_execute to form a SQL query that uses user input, SQL could be injected.

aaa'; DROP TABLE Docs;--

Uses a single quotation mark to break out of the current SQL query.

aaa' DROP TABLE Docs;--

A semicolon isn’t always needed to break out of a query.

-- Comment
/* Comment */
// Comment

Use different commenting tricks to stop the rest of the query from being processed.

5; DROP TABLE Docs;--

Single quotation marks aren’t needed if the input is used where a numerical value is used.

ASC; DROP TABLE Docs

ASC and DESC are used in an SQL query to order the results. If those values are supplied by the user, it might be possible for an attacker to cause a SQL injection.

Check for safe for scripting and safe for initialization

COM objects that are marked safe for scripting and safe for initialization can potentially be repurposed in a malicious Web site.

Check if Sitelock is implemented

If the ActiveX control uses Sitelock, try to bypass it using URL encoding tricks, IP obfuscation, etc.

Identify how each method can be abused or repurposed

See if methods can do things beyond what was intended. For example, accessing a file on a network share, making HTTP requests, performing local file operations, etc.

Use error handling

By using error handling you can look for information disclosure bugs.

Find unsafe nested objects

By accessing unsafe objects through your control, you can do whatever is unsafe in those objects.

Check DllCanUnloadNow reference counting

If the DLL can be unloaded prematurely, arbitrary code can be run.

Look for spoofing issues

Often, to mitigate security concerns, dialog boxes are displayed that can be fooled.

Look for overflows

Test each persistent property, method, and event parameter for overruns.

Test that control doesn’t bypass browser security

The browser includes a lot of security around pop-ups, cross-domain access, and so forth; make sure your control doesn’t make that security useless.