slide1 l.
Skip this Video
Loading SlideShow in 5 Seconds..
Web Security Prepared From The Open Web Application Security Project WWW.OWASP.COM by David Wilczynski PowerPoint Presentation
Download Presentation
Web Security Prepared From The Open Web Application Security Project WWW.OWASP.COM by David Wilczynski

Loading in 2 Seconds...

play fullscreen
1 / 83

Web Security Prepared From The Open Web Application Security Project WWW.OWASP.COM by David Wilczynski - PowerPoint PPT Presentation

  • Uploaded on

Web Security Prepared From The Open Web Application Security Project WWW.OWASP.COM by David Wilczynski The Dangers of which Programmers Should Be Aware HTTP, Web Browsers, GUIs 2 nd Tier Application on WebServer communicating with 1 st Tier browser are usually on separate machines.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Web Security Prepared From The Open Web Application Security Project WWW.OWASP.COM by David Wilczynski' - libitha

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Web SecurityPrepared From The Open Web ApplicationSecurityProjectWWW.OWASP.COMbyDavid Wilczynski

The Dangers of which Programmers Should Be Aware

http web browsers guis
HTTP, Web Browsers, GUIs
  • 2nd Tier Application on WebServer communicating with 1st Tier browser are usually on separate machines.
  • You can’t be sure the input is coming from a trusted user or even the user you are dealing with.
  • The HTTP you expect from the client may be “spoofed” by an intruder.
  • Ten Most Critical Web Security Vulnerabilities
1 unvalidated input
1. Unvalidated Input
  • Information from web requests is not validated before being used by a web application.
  • Attackers can use these flaws to attack backend components through a web application.
2 broken access control
2. Broken Access Control
  • Restrictions on what authenticated users are allowed to do are not properly enforced.
  • Attackers can exploit these flaws to access other users' accounts, view sensitive files, or use unauthorized functions.
3 broken authentication and session management
3. Broken Authentication and Session Management
  • Account credentials and session tokens are not properly protected.
  • Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users' identities.
4 site scripting xss flaws
4. Site Scripting (XSS) Flaws
  • The web application can be used as a mechanism to transport an attack to an end user's browser.
  • When a user is tricked into clicking on a malicious link or submitting a specially crafted form, the injected code travels to the vulnerable web server, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a ‘trusted’ server.
5 buffer overflows
5. Buffer Overflows
  • Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process.
  • These components can include CGI, libraries, drivers, and web application server components.
6 injection flaws
6. Injection Flaws
  • Web applications pass parameters when they access external systems or the local operating system.
  • If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application.
7 improper error handling
7. Improper Error Handling
  • Error conditions that occur during normal operation are not handled properly.
  • If an attacker can cause errors to occur that the web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server.
8 insecure storage
8. Insecure Storage
  • Web applications frequently use cryptographic functions to protect information and credentials.
  • These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection.
9 denial of service
9. Denial of Service
  • Attackers can consume web application resources to a point where other legitimate users can no longer access or use the application.
  • Attackers can also lock users out of their accounts or even cause the entire application to fail.
10 insecure configuration management
10. Insecure Configuration Management
  • Having a strong server configuration standard is critical to a secure web application.
  • These servers have many configuration options that affect security and are not secure out of the box.
1 unvalidated input13
1. Unvalidated Input
  • Attackers can tamper with any part of an HTTP request, including the url, querystring, headers, cookies, form fields, and hidden fields, to try to bypass the site's security mechanisms
  • Attacks include: forced browsing, command insertion, cross site scripting, buffer overflows, format string attacks, SQL injection, cookie poisoning, and hidden field manipulation
parameter specification
Parameter Specification
  • Data type (string, integer, real, etc…)
  • Allowed character set
  • Minimum and maximum length
  • Whether null is allowed
  • Whether the parameter is required or not
  • Whether duplicates are allowed
  • Numeric range
  • Specific legal values (enumeration)
  • Specific patterns (regular expressions)
example scenario
Example - Scenario
  • You are to populate a list with accounts provided by the back-end (3rd tier) system. The user will choose an account, choose a biller, and press next.
  • Wrong WayThe account select option is read directly and provided in a message back to the backend system without validating that the account number is one of the accounts originally provided by the backend system.
a good way
A Good Way

acc = session.getParameter('payeelstid‘);

if account.inList(acc)


else error();

a better way
A Better Way

int payeeLstId = session.getParameter('payeelstid');

accountFrom = account.getAcctNumberByIndex(payeeLstId);

The above field cannot be tampered with.

data validation strategies
Data Validation Strategies
  • There are four strategies for validating data, and they should be used in this order:
    • Accept known good
    • Reject known bad
    • Sanitize
    • Accept without validation
accept known good best
Accept known good (Best)
  • If you expect an integer, check for one.
reject known bad
Reject known bad

If you don't expect to see characters such as %3f or JavaScript or similar, reject strings containing them:

public String removeJavascript(String input) {

Pattern p = Pattern.compile("javascript", CASE_INSENSITIVE);


return (!p.matches()) ? input : '';


  • Eliminate or translate characters in an effort to make the input "safe."
  • This does not work well in practice, as there are many, many exceptions to the rule.

public String quoteApostrophe(String input) {

return str.replaceAll("[\']", "’");


no validation
No validation



2 broken access control23
2. Broken Access Control
  • Access control, or authorization, is how a web application presents content and functions to some users and not others.
  • These checks are performed after authentication, and govern what ‘authorized’ users are allowed to do.
  • Few use an access control matrix to define the access control rules.
principle of least privilege
Principle of least privilege
  • Far too often, web applications run with excessive privileges.
  • Never use “Administrator”, “root”, “sa”, “sysman”, “Supervisor” to run the application.
access control lists
Access Control Lists
  • Many access controls are out of the box insecure.
  • For example, the default Java 2 file system security policy is “All Permission”

grant codeBase "file:${{java.ext.dirs}}/*" {



client side authorization tokens
Client-side authorization tokens
  • Many web application developers are keen to not use session storage – which is misguided when it comes to access control and secrets.
  • So they revert to using the client’s state, either in cookies, headers, or in hidden form fields.
3 broken authentication and session management27
3. Broken Authentication and Session Management
  • Handling user authentication and managing active sessions.
  • Can be undermined by flawed credential management functions, including password change, forgot my password, remember my password, account update, and other related functions.
  • Because of “walk by” attacks, all account management functions need reauthentication even if the user has a valid session id.
best practices
Best Practices
  • Authentication is only as strong as your user management processes, and in particular the user issuance and evidence of identity policies.
  • Use the most appropriate form of authentication suitable for your asset classification.
    • For example, username and password is suitable for low value systems such as blogs and forums
    • SMS challenge response is suitable for low value e-commerce systems (in 2005),
    • transaction signing is suitable for high value systems such as high value e-commerce, banking and trading systems.
best practices cont
Best Practices (cont).
  • Re-authenticate the user for high value transactions and access to protected areas (such as changing from user to administrative level access)
  • Authenticate the transaction, not the user. Phishers rely on poorly implemented user authentication schemes
  • Passwords are trivially broken and are unsuitable for high value systems. Any password less than 16 characters in length can be brute forced in less than two weeks, so set your password policy to be reasonable.
more on passwords
More on Passwords
  • Train your users to use suitable passwords.
  • Allow your users to write down their passwords as long as they keep them safe
  • Encourage pass phrases instead of passwords
  • Relax password expiry requirements upon the strength of the password chosen—easy passwords should have an expiry of 30 days, and good ones probably do not need a hard expiry limit, but a gentle reminder after (say) 90 days instead.
  • Modern browsers offer users the ability to manage their credentials by storing them insecurely on their computer.
remember me
Remember Me
  • On public computers, “Remember Me?” functionality, where a user can simply return to their personalized account can be dangerous.
  • For example, in Internet Cafes, you can often find sites previous users have logged on to, and post as them, or order goods as them (for example with eBay).
session management
Session Management

To ensure that

  • authenticated users have a robust and cryptographically secure association with their session
  • enforce authorization checks
  • prevent common web attacks, such as replay, request forging and man-in-the-middle attacks
  • Best practice is to not re-write the wheel, but to use a robust, well-known session manager.
permissive session generation
Permissive Session Generation
  • Many web application frameworks will simply issue a new requestor a valid session ID if one does not exist.
  • This is called “permissive session generation”
  • Coupled with some forms of phishing and an associated lack of authorization, this attack can be devastating.
how to determine if you are vulnerable
How to determine if you are vulnerable
  • Open a fresh browser to connect to a protected page or action deep in the application.
  • If a new session ID is generated and the page works, the authorization is falsely assuming the validity of the session variable.
how to protect yourself
How to protect yourself
  • When starting a fresh session object for a user, make sure they are in the “logged off” state and are granted no role.
  • Ensure that each protected page or action checks the authentication state and authorization role before performing any significant amount of work, including rendering content.
  • Ensure that all unprotected pages use as few resources as possible to prevent denial of service attacks, and do not leak information about the protected portion of the application
session time out
Session Time-out
  • Session tokens that do not expire on the HTTP server allow an attacker unlimited time to guess or brute-force a valid authenticated session token.
  • If a user's cookie file is captured, then an attacker can use these static-session tokens to gain access to that user's web accounts.
  • A problem especially in environments where computers are shared.
session hijacking
Session Hijacking
  • When an attacker intercepts or creates a valid session token on the server, they can then impersonate another user.
  • Session hijacking can be mitigated partially by providing adequate anti-hijacking controls in your application.
  • The easiest type of web application to hijack are those using URL based session tokens used in Internet cafes.
4 cross site scripting xss flaws
4. Cross-Site Scripting (XSS) Flaws
  • An attacker can send a malicious script to an unsuspecting user. A variant of the Trojan Horse.
  • Often, the end user’s browser has no way to know that the script should not be trusted, and will execute the script.
  • Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site.
xss stored and reflected
XSS: Stored and Reflected
  • Stored attacks are those where the injected code is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc.
    • The victim then retrieves the malicious script from the server when it requests the stored information.
reflected attacks
Reflected Attacks
  • Injected code is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request.
    • Reflected attacks are delivered to victims via another route, such as in an e-mail message
    • When a user is tricked into clicking on a malicious link or submitting a specially crafted form, the injected code travels to the vulnerable web server, which reflects the attack back to the user’s browser.
    • The browser then executes the code because it came from a ‘trusted’ server.
5 buffer overflow
5.Buffer Overflow
  • Attackers use buffer overflows to corrupt the execution stack of a web application.
  • By sending carefully crafted input to a web application, an attacker can cause the web application to execute arbitrary code - effectively taking over the machine.
  • Attackers have managed buffer overflows in a staggering array of products and components.
  • Sending large inputs can cause the web application or the back-end database to malfunction.
stack overflow
Stack Overflow
  • The source buffer contains arbitrary attack input, and the destination buffer is too small to contain the attack input. The second buffer is on the stack, near the function return address on the stack.
  • The faulty code without checking size, copies the hostile data into the second buffer, obliterating the second buffer and the stack’s return address.
  • When the function returns, the CPU unwinds the stack frame and pops the faulty return address from the stack, which now points to attack code.
  • The attack code is executed instead of returning to the application’s previous caller
heap overflow
Heap Overflow
  • A heap is an area of memory allocated by the application run time to store locally declared variables.

function foo(char *bar) {

char thingy[128];



  • bar is passed via the stack, whereas thingy is allocated on the heap. The overflow possibilities are exploitable just like stack overflows.
  • Validate user input to prevent overlong input and check the values to ensure they are within spec (i.e. A-Z, a-z, 0-9, etc).
integer overflow
Integer Overflow
  • When an application takes two numbers of fixed word size and perform an operation with them, the result may not fit within the same word size.
  • For example, if two 8 bit numbers 192 and 208 are added together and stored into another 8-bit byte, the result will simply not fit into the 8 bit result.
how to protect yourself45
How to protect yourself
  • .NET: Use David LeBlanc’s SafeInt<> C++ class.
  • If your compiler supports it, change the default for integers to be unsigned unless otherwise explicitly stated. Use unsigned whenever you mean it.
  • Use range checking if your language or framework supports it.
  • Be careful when using arithmetic operations near small values, particularly if underflow or overflow, signed or other errors may creep in.
6 injection flaws46
6. Injection Flaws
  • Injection flaws allow attackers to relay malicious code through a web application to another system.
  • These attacks include calls to the operating system via system calls, the use of external programs via shell commands, as well as calls to backend databases via SQL (i.e., SQL injection).
  • Whole scripts written in perl, python, and other languages can be injected into poorly designed web applications and executed.
  • Any time a web application uses an interpreter of any type there is a danger of an injection attack.
immediate reflection
Immediate Reflection
  • The victim is encouraged/forced to a vulnerable page, such as a link to cute kittens, a redirect page to “activate” an account, or a vulnerable form which contains an improperly sanitized field.
  • Once the user is on the vulnerable destination, the embedded reflection attack launches the attacker’s payload. Even though GET requests need to be less than 2 or 4 KB in size, this has proved ample .
  • Nearly all phishing attempts are like this.
stored injection attack
Stored Injection Attack
  • The injection occurs at a previous time and users are affected at a later date.
  • The usual type of attack are blog comments, forum, and any relatively public site which can be compromised in some fashion.
protecting against reflected attacks
Protecting against Reflected Attacks
  • Strong input validation should remove suspicious characters.
  • In ASP.NET, you should add this line to your web.config:

<pages validateRequest="true" />

in the <system> </system> area.

protecting against stored attacks
Protecting against stored attacks

With unclean sources, output validation is required.

  • ASP.NET: In web.config – validateRequest to be true and use HTTPUtility.HTMLEncode() for body variables.
  • PHP: Use htmlentities(), htmlspecialchars(), for HTML output, and urlencode() for GET arguments.
  • JSP: Output validation is actually very simple for those using Java Server Pages - just use Struts, such as using <bean:write ... > and friends:
    • Good: <html:submit styleClass="button" value="<bean:message key="button.submitText /> "/>
    • Bad: out.println('<input type="submit" class="button" value="<%=buttonSubmitText%>" />');
http response splitting
HTTP Response Splitting
  • In HTTP, the headers and body are separated by a double carriage return line feed sequence.
  • The attacker can insert data into a header, such as the location header (used in redirects) or in the cookie. If the application does not protect against CRLF injection, it is vulnerable.
  • The attack injects two responses (thus the name),
    • the first response is the attacker’s payload,
    • the second response containing the rest of the user’s actual output, is usually ignored by the web server.
how to protect yourself52
How to protect yourself
  • Investigate all uses of HTTP headers, such as:
    • setting cookies
    • using location (or redirect() functions)
    • setting mime-types, content-type, file size, etc
    • or setting custom headers
  • If these contain unvalidated user input, the application is vulnerable if the application cannot detect this issue.
sql injection
SQL Injection
  • SQL Injection can occur with every form of database access. However, some forms of SQL injection are harder to obviate than others:
    • Parameterized stored procedures, particularly those with strongly typed parameters
    • Prepared statements
    • ORM (eg Hibernate)
    • Dynamic queries
dynamic sql injection is still a favorite amongst php
Dynamic SQL injection is still a favorite amongst PHP

The state of the art has advanced significantly:

  • It is possible to perform blind (and complete) injection attacks using timing based attacks.
  • It is possible to obviate certain forms of stored procedures, particularly when the stored procedure is just a wrapper

The application should:

  • All SQL statements that affect data should ensure that the data is updated based on the user's record.
  • Have at least one automated test try to perform a SQL injection.
ldap l ightweight d irectory a ccess p rotocol injection
LDAP (Lightweight Directory Access Protocol, ) Injection
  • LDAP injections are relatively rare at the time of writing, but they are devastating if not protected against.
  • LDAP injections are thankfully relatively easy to prevent: use positive validation to eliminate all but valid username and other dynamic inputs.
example creates an entry for username and password
Example:Creates an Entry for Username and Password

String principal = "cn=" + getParameter("username") + ", ou=Users, o=example";

String password = getParameter("password");

env.put(Context.SECURITY_AUTHENTICATION, "simple");

env.put(Context.SECURITY_PRINCIPAL, principal);

env.put(Context.SECURITY_CREDENTIALS, password);

// Create the initial context

DirContext ctx = new InitialDirContext(env);

solution add the following
Solution: Add the following

// if the username contains LDAP specials, stop now

if (containsLDAPspecials( getParameter("username"))) {

throw new javax.naming.AuthenticationException();


and there is more
And there is more…
  • XML Injection
    • Many systems now use XML for data transport and transformation.
  • Attack paths - Blind XPath Injection
    • XPath is used for everything from searching for nodes within an XML document right through to user authentication, searches and so on.
  • Code Injection
    • ASP.NET is vulnerable through the use of CodeProvider classes along with reflection.
    • PHP code which uses eval() is at risk.
    • Java’s evaluating dynamic JSPs has some flaws. Prefer static includes ( <% include ... %> ).
  • Phishing attacks banking and e-commerce.
  • Potential to destroy a customer’s livelihood and credit rating and a company’s reputation.
  • There are a few precautions that application writers can follow to reduce the risk, but most phishing controls are procedural and user education.
  • Up to 5% of users seem to be lured into these attacks, so it can be quite profitable for scammers – many of whom send millions of scam e-mails a day.
the scam
The Scam
  • Delivery via web site, e-mail or instant message, the attack asks users to click on a link to “re-validate” or “re-activate” their account. The link displays a believable facsimile of your site and brand to con users into submitting private details
  • Sends a threatening e-mail to users telling them that the user has attacked the sender. There’s a link in the e-mail which asks users to provide personal details
  • Installs spyware that watches for certain bank URLs to be typed, and when typed, up pops a form that asks the users for private details.
  • Installs spyware that watches for POST data, such as usernames and passwords, which is then sent onto a third party system.
  • Installs spyware that dredges the host PC for information from caches and cookies.
  • “Urgent” messages that the user’s account has been compromised, and they need to take some sort of action to “clear it up”.
  • Messages from the “Security” section asking the victim to check their account as someone illegally accessed it on this date. Just click this trusty link…
user education
User Education
  • Users are the first, and often the last, lines of defense, and therefore any workable solution must include them.
  • Create a policy detailing exactly what you will and will not do. Regularly communicate the policy in understandable terms Make sure the policies are on your web site.
  • Ask your users to install anti-virus software, anti-spyware, keep it up to date, scanned recently, and have updated their computer with recent patches. Keep basic computer hygiene in the users’ minds.
  • Team with anti-virus firms to offer special deals to your users to provide low cost protection for them (and you).
learned helplessness
Learned Helplessness
  • However, be aware that user education is difficult.
  • Users have been lulled into “learned helplessness”
  • They actively ignore privacy policies, security policies, license agreements, and help pages.
  • Do not expect them to read anything you communicate with them.
  • Make it easy for your users to report scams
much much more
Much, much more…
  • Learn how to communicate with customers via e-mail
  • Never ask your customers for their secrets
  • Fix all your XSS issues
  • Do not use pop-ups
  • Don’t be framed
  • Move your application one link away from your front page
  • Enforce Request Based Blocking
  • Keep the address bar, use SSL, do not use IP addresses
  • Don’t be the source of identity theft
  • Implement safe-guards within your application
  • Monitor unusual account activity
  • Get the phishing target servers offline pronto
  • Take control of the fraudulent domain name
  • Work with law enforcement
7 improper error handling64
7. Improper Error Handling
  • Detailed internal error messages such as stack traces, database dumps, and error codes are displayed to the attacker.
  • These messages reveal implementation details that should never be revealed (and are disturbing to regular users).
  • Out of memory, null pointer exceptions, system call failure, database unavailable, network timeout, and others happen:
    • must provide a meaningful error message to the user, diagnostic information to the site maintainers;
    • no useful information to an attacker.
functional return values
Functional return values
  • Many languages indicate an error condition by return value. E.g.:

$query = mysql_query(‘SELECT * FROM table WHERE id=4’, $conn);

if ( $query === false ) {

// error


  • Are all functional errors checked?
  • If not, what can go wrong?
  • Logs should be written so that only new information can be written (older records cannot be rewritten or deleted). Also:
    • Copies kept and moved to permanent storage
    • Log files and media should be deleted and disposed of properly
    • Keep logs safe and confidential even when backed up.
handling log files
Handling Log Files
  • Logs can be fed into real time intrusion detection and performance and system monitoring tools.
  • All logging components should be synced with a timeserver so that all logging can be consolidated effectively without latency errors. This time server should be hardened and should not provide any other services to the network.
  • No manipulation, no deletion while analyzing.
  • Intentionally invoking security errors can fill an error log with noise to hide a successful intrusion.
how to protect yourself68
How To Protect Yourself
  • Beware of the attacker who can delete or manipulate log entries "as though the event never even happened!".
  • Beware of false alarms (“Crying Wolf”):
    • The attacker may be trying to fool you into blaming and not trusting the technology.
    • false alarms may cause denial of service by filling up logs and disabling your system.
    • Don’t configure log file to cycle round overwriting old entries when full. Obvious flaw.
8 insecure storage and encryption
8. Insecure Storage and Encryption
  • Web applications store sensitive information, either in a database or on a file system somewhere.
  • The information might be passwords, credit card numbers, account records, or proprietary information.
  • Encryption techniques are used to protect this sensitive information, but mistakes happen.
  • Worse, developers may overestimate the protection gained by using encryption and not be as careful in securing other aspects of the site.
common encryption mistakes
Common Encryption Mistakes
  • Failure to encrypt critical data
  • Insecure storage of keys, certificates, and passwords
  • Improper storage of secrets in memory
  • Poor sources of randomness
  • Poor choice of algorithm
  • Attempting to invent a new encryption algorithm
  • Failure to include support for encryption key changes and other required maintenance
reversible authentication tokens
Reversible Authentication Tokens
  • Differentiating between users is often done through cookies or other session identifiers.
  • Must ensure attacker can’t predict their sequence, i.e., true random numbers.
    • Windows & .NET: CryptGenRandom function
    • Unix: OpenSSL is one of the recommended options. On some platforms, /dev/urandom is suitable.
    • PHP: mt_rand() is much worse than CryptoAPI’s secure random number generation options, OpenSSL, or /dev/urandom.Do not use rand() as it is very weak.
    • Java: within the Java Cryptography Extension (JCE) provides secure random numbers.
cryptographic functions
Cryptographic Functions

Authentication - To establish the identity of a remote user (or system). E.g. a web server providing a SSL certificate of a providing proof to the user.

Non-Repudiation - To prove that a unique user made a transaction. It must not be possible for the user to refute his or her actions.

Confidentiality - To keep information private. Encryption allows only users who have access to the decryption key to get access to the data.

Integrity - To ensure data is not viewed or altered during storage or transmission. Cryptographic hashes can safeguard data with a secure checksum.

cryptographic algorithms
Cryptographic Algorithms

Public/Private Key - Use two keys, one to encrypt the data, and either key to decrypt. These inter-dependent keys are generated together. One is labeled the Public key and is distributed freely. The private key must be kept secure.

Symmetric keys share a common secret (password, pass phrase, or key).

Hash functions take some data (and possibly a key or password) and generate a unique hash or checksum.

Key exchange algorithms allow use to safely exchange encryption keys with an unknown party.

Combinations – SSL for example. Establish a connection with public/private key, then encrypt the actual transmission with a weaker, but much faster algorithm.

more to do
More to do…

Key Storage - It is vital that the keys are adequately protected. Any compromised system should have all its keys replaced.

Insecure transmission of secrets - Ensure that encryption occurs before we transmit the data onto any untrusted network.

9 denial of service75
9. Denial Of Service
  • Objective
    • To ensure that the application is robust as possible in the face of denial of service attacks.
  • How to protect yourself
    • Only allow authenticated and authorized users to consume significant CPU resources.
    • Re-code to prevent the basic default requests from consuming too much CPU time.
things to watch for
Things to Watch For

Excessive CPU consumption

Many non-trivial business requests, such as report generation and statistical analys can consume quite large chunks of CPU time. Validate users.

Excessive disk I/O consumption

Database searches, large images, and huge cheap disks lead to unending requests for more disk I/Os. Validate your user.

Excessive disk I/O consumption

Use a DoS shield to help, however, these devices don’t help if the upstream infrastructure has been overwhelmed .

user account lockout
User Account Lockout
  • A common denial of service attack is to lockout user accounts if an account lockout policy is in place.
  • Record user lockout requests.
    • If more than one account is locked out by the same IP address in a short time, prevent it.
    • Automatically unlock accounts after 15 minutes
10 insecure configuration management78
10. Insecure Configuration Management
  • Web server and application server configurations play a key role in the security of a web application. They define what services are available, including data storage, directory services, mail, messaging, and more.
  • Frequently, the web development group is separate from the group operating the site.
  • Web application security concerns often span this gap and require members from both sides of the project to properly ensure the security of a site.
typical problems
Typical Problems
  • Unpatched security flaws in the server software
  • Server software flaws or misconfigurations that permit directory listing and directory traversal attacks
  • Unnecessary default, backup, or sample files, including scripts, applications, configuration files, and web pages
  • Improper file and directory permissions
  • Unnecessary services enabled, including content management and remote administration
  • Default accounts with their default passwords
  • Administrative or debugging functions that are enabled or accessible
  • Overly informative error messages (see also error handling section)
  • Misconfigured SSL certificates and encryption settings
  • Use of self-signed certificates to achieve authentication and man-in-the-middle protection
  • Use of default certificates
  • Improper authentication with external systems
best practices80
Best Practices
  • Turn off all unnecessary features by default
  • Ensure that all switches and configuration for every feature is configured initially to be the safest possible choice
  • Inspect the design to see if the less safe choices could be designed in another way. For example, password reset systems are intrinsically unsound from a security point of view.
  • Do not rely on optionally installed features
  • Do not configure anything in preparation for an optionally deployable feature.
configuration issues
Configuration Issues

Default passwords

Applications often ship with well-known passwords. In a particularly excellent effort, NGS Software determined that Oracle’s “Unbreakable” database server contained 168 default passwords out of the box.

Secure connection strings

Connection strings to the database are rarely encrypted. However, they allow a remote attacker who has shell access to perform direct operations.

Secure network transmission

By default, no unencrypted data should transit the network.

configuration issues cont
Configuration Issues (cont.)

Encrypted data

Some information security policies and standards require the database on-disk data to be encrypted. However, this is essentially useless if the database connection allows clear text access to the data.

Database security

  • Data obtained from the user needs to be stored securely.
  • The application should connect to the database using as low privilege user as is possible.
  • The application should make use of safer constructs, such as stored procedures and not access table directly.
  • Don’t deploy the database server on the main network. Put it on another host, which should be locked down with all current patches and latest database updates.
and that s not all
And that’s not all…

…but it is for us.