no notes exist for this slide

no notes exist for this slide

no notes exist for this slide

no notes exist for this slide

Each of these photos represents a different type and level of security Camera: Kind of like security logs. Great for observation without being noticed. But they cannot act and they are not worth anything if no one looks at feeds or the tapes Safe: REALLY secure, similar to unplugging a machine from the network and locking it in a closet. The problem is, then almost no one can access the info, and it is only protected by a single password when someone does need access Guard Dog and Armed Office patrolling a building: great for observation and for deterring attacks Security with Human intelligence. But high maintenance and expensive and not infallible Some could get around this line of defense cause ut can't be everywhere at once Presidential motorcade – Ultimate security. WHICH TYPE DO YOU NEED FOR YOUR APPLICATION?

More specifically, the stakeholders of the project decide You need to meet and develop a Security Policy The security policy defines what it means for the application to be secure “Secure” must first be defined before it can be enforced Policy must be enforced Some outside forces may be involved in determining what is secure, like PCI and HIPAA

Of course the answer is yes In an Enterprise, it should be expected, accountability, legal, cross I's and dot T's In a small shop AND enterprise it helps to make sure everyone is on the same page Even in a one-person shop it can help the developer make security PART OF the app from the very beginning instead of making it an after thought And in ALL of the above, it is due diligence in ensuring that the application is secure. This reassures you and your client and will help protect you if your application ever does get hacked and your client decides to sue you over it If you have a security policy that was agreed upon by you and the client...

Definitions Requirements Rules & Regulations Procedures

Access Requirements • Assets Files (Source, Images, Flash, System) Data (DB, config files, etc) Hardware (Web and DB servers) Responsible Parties and roles Data Stewards Developers Reviewers Who is responsible for ensuring what? Risks Loss of businesses Legal costs Reputations Consequences of violating the policy

Common Requirements Business Rules External Requirements Response Requirements Access Requirements • Change Management Req • Physical Security Requirements • Logon ID and Password Requirements • Virus Protection Requirements • Data Backup Requirements • BC/DR Plan Requirements

Username & Password Encryption User Input Validation File Uploads Workflow for approval Secure Connections Error Handling Access Controls APIs Object Reference File retrieval Session and Cookie Management

Procedures must be spelled out so there is no room for error Data Backup Where are they stored? Off-Site? Off-Entity? Disaster Recovery What to do when there is an incident Continuance of Operation If COOP is defined in the needs, then a procedure for it need to be established Common Countermeasures

Procedures must be spelled out so there is no room for error Flexible means allow for exceptions where there is a business need that trumps the security need or where you accept one countermeasure over another in a specific case Policy needs to be reviewed by developers, client, and all stake holders When possible, having the policy reviewed by an outside party.

no notes exist for this slide

Least Privilege Least amount of privilege required to perform their business processes Defense in Depth where one control would be reasonable, more are better for example, just cause you have filters in place for XSS doesn;t mean a WAF would not help Secure Defaults Default Deny, white list validation may be harder... Give the user a really secure password by default and let them change it Don't trust services, they are still third-parties Fix it right it may be wide spread

Contrived example, but the principle is sound

Opposite of a neg sec model which defines what is not allowed and allows everything else White listing defines what IS allowed and denies everything else This can stop new attacks and does not require us to try to figure out every possible attack If a username only allows letters, then define it to only allow letters Validation Validation Validation

Can be used to obtain, change, or destroy data Can be used to execute system commands Is one of the easiest attacks to perform Is also one of the easiest attack to prevent Can be done against any DBMS

FORM, URL, COOKIE and CGI scopes Look at a URL example

Standard, ugly blog Two completely unrelated tables One from public facing, one from admin section Can one be used to exploit the other?

Negates the first query with 1=0 Adds a second query that gets a single user This query will result in one record The query column names from the first query will still be used. So username will go to blog title and password will go to BlogText

Negates the first query with 1=0 Adds a second query that gets a single user This query will result in one record The query column names from the first query will still be used. So username will go to blog title and password will go to BlogText

It's actually MORE important to use query params in CFScript queries because they are easier to exploit No magic quotes

Lists work in either, but I have not yet been able to use named params for the cfscript version.

Lists work in either, but I have not yet been able to use named params for the cfscript version.

XSS Vulnerabilities come in 3 flavors: DOM-Based (Type 0)‏ A DOM-Based XSS vulnerability is exploited through pages that, somehow, exist on the local machine of the victim, Non-Persistent (Type 1)‏ Non-persistent vulnerabilities are the most common to be exploited by XSS attacks. The vulnerability exists when information sent to a page is immediately used on the receiving page without being properly prepared for display. Persistent (Type 2)‏ Persistent XSS is, as the name suggests, an attack that is implemented and then lasts until it is removed. It is generally deployed through the use of a web form, like SQL Injection,

Basic blog comments textarea Someone inserts a script tag If nto handled, the JS will excute Now, this (seemingly harmless) script would be nothing more than vandalism. In the eyes of your end users this represents a huge security hole Word would spread quickly that your site had been hacked. Cross-Site Scripting can be used for much worse things then displaying an Alert window.

Here is a more dangerous XSS. If someone can get you to browse to a page on a site that has this JS in it, your cookies will be sent to the evil site.

Persistent XSS would be similar except the exploit payload would come from the DB or some other persistent means other than from the hacker.

First and for most, Validate, Validate, Validate No where your unstrusted data is coming from CGI (Header), FORM, URL, COOKIE, even web services that have been exploited or other user interfaces to the same backend Never ever ever put untrusted input directly into a javascript context, into a comment or into a tag name or attribute name. Period, just don't, regardless of how you escape/encode it Inside of NORMAL HTML elements, you can use HTML Encoding

Always Quote your variables and attribute values Use JSStringFormat() in these cases Using the ESAPI JSEncoder is even better

Always Quote your variables and attribute values Use JSStringFormat() in these cases Using the ESAPI JSEncoder is even better

no notes exist for this slide

A request forgery, also sometimes called a Cross-Site (or On-Site) Request Forgery(XSRF), is an attack that is perpetrated against the user of a site who has authenticated access to that site The user is unwittingly tricked into performing actions on a site through hidden code displayed to them and, therefore, executed in their browser The hacker is writing a check and you're cashing it for him, without knowing it

How about an Example? Delete page/function single parameter PageID Admin Only All is good, right?

One morning, Bob (one of our administrators) gets an email from Kay in accounting. It has a link to a bad joke on a Joke-of-the-Day site Bob finishes the joke, chuckles politely and deletes the email About 5 minutes later, the phone starts ringing. The company website is down WHAT HAPPENED?? The email Bob received wasn't from Kay in accounting It was from a Hacker who spoofed Kay's email address The link the hacker sent, did go to a Joke-of-the-Day pages, but the hacker left a comment for the joke and in his comment he placed the line:

no notes exist for this slide

no notes exist for this slide

So let's say we have a form that looks like this: Assume that it has other appropriate security to ensure only administrators have access The page or function this POSTs to is likely vulnerable to the forgery attack we just looked at

Create a UUID (or GUID) Add that UUID to the form and the user session We can then check the result in the action page/method to confirm that it came from the right place

Another option is to ask for a second verification. Prompt “Are you sure?” Maybe even require them to enter their password again

no notes exist for this slide

How do we get a secure password? Does every site need a “super” secure password? Password Best Practices Password Salting and Hashing Password Strength Function “Forgot My Password” Best Practices

alphabetical and numeric characters uppercase and lowercase letters special characters at least 7 or 8 characters long be changed every [Insert period of time here]. never contain the username or be a date

Do you need a $20,000 safe? Does every site need a “super” secure password? It is a judgment call, get the input of the people to whom data belongs There is no reason not to allow a strong password At a minimum, set a decent minimum length and require some alphas and some numerics Best Practices Don't set a minimum length above 8 character Where possible, use SSL Load the login form using SSL (although it only needs to POST to SSL)‏ Don't send Login credentials on th URL string (except for Web Services, and then, only over SSL)‏ Never store passwords in clear text Create an audit log of login attempts If you lock a user out after a certain number of login attempts, do not use a cookie or tie it to the user session, do it in the database

From Wikipedia: "... a Cryptographic Hash Function is a transformation that takes an input and returns a fixed-size string, which is called the hash value. A hash is a One-Way Transformation A strong enough hash is virtually impossible to reverse A strong enough hash will have very few collisions We do it to transform a user's password into an irreversible string so that even if it becomes compromised, it cannot be used to determine the password

no notes exist for this slide

MD5 Hash is not strong enough MD5 is fine for examples, but in the real world, MD5 is weak So what are the other options?

So let's compare the algorithms

no notes exist for this slide

no notes exist for this slide

no notes exist for this slide

A specific string will ALWAYS result in the same hash value Collisions occur when two values have the same Hash value Strong hashing algorithms are going to have fewer collisions The longer the hash value, the less likely you will have collisions. COMMON QUESTION So if hashes aren't reversible, how can we tell if the user entered the correct password? When the user enters their password, while logging in, we hash it and compare the result to the hash that we stored in the database. Since a hash cannot be reversed, even if the DB becomes compromised, the information cannot be used to obtain password, nor can it be used to login using the hash instead of a password

What is Salting? Why we need salting We need salting because people make stupid password We also need passwords because hackers are smart If our passwords becomes compromised, and the passwords are hashed, then the hacker will start looking for like values If the hacker finds two hashed values that are exactly the same then that value is either a common dictionary word, a name, a date, or a stupid password The brute force attack on that user can then commence Salting ensures that no two hashes in our database ever have the same value, even if they are the same password Salting is the process of adding a random string of characters to the end of a user's password before hashing it. Each password would get its own salt hence eliminating the problem of two like passwords having the same hash value.

no notes exist for this slide

Notice the hash without salting is identical between the two values But, once you add a salt, the two values are very different Of course, we need to store the salt that we use for each value so that when we hash the user input, we can append the salt

Never have your “Forgot My Password” function e-mail the users password (If you are hashing password you won't be able to anyway)‏ Either reset the users password and email them the new password or send the user a temporary URL that can be used for them to reset the password Force the user to change their password after they first log in after a reset Keep a log of the last X hashes of the users password so they cannot reset their password to something that have used previously (Within reason)‏ Make sure your Change Password functionality uses the same strength and hashing functions as your initial password set up Iterate your hashes 1000 times or more to slow down brute forcing and rainbow table attacks Do not login a user from the “Forgot My Password” section. Always make them go through their e-mail.

What is a Session? Session Tokens Session Persistence Session Hi-Jacking Session Fixation Session Hi-Jack through XSS Brute-Force Session Hi-Jack Session Token Best Practices

Since the World Wide Web is stateless, we need sessions to persist data Session Management is a way to create statefulness in a stateless environment Each client is assigned a session token, used from request to request Information that is stored on the server can be provided to the client that provides the correct token After initial authentication, session management takes over and persists that authentication from request to request If the session token can be compromised then whoever gains access to a valid session token can impersonate the user to whom that token belongs That's called Session Hi-Jacking and all a hacker needs to accomplish a session hi-jacking is the session token How can the session token become compromised? Physical Access to a machine Sessions Fixation XSS Social Engineering Brute-Force Guessing

no notes exist for this slide

Sessions can be persisted in 3 ways Passing in a URL (Tough to maintain) Developer has to remember to always pass the URL string End user can easily lose their session by messing with the URL Session Token will be logged by the web server Passing in POST requests (Very difficult to maintain) EVERY request from page to page needs to be a <form> Even Navigation Using a Token Cookie (Easy to do, easy to maintain, easier to secure) End user would have a hard time screwing it up Does require that your end users have cookies enabled

This solves three problems 1. Sessions token cookies are made SECURE (Only use this in SSL) 2. Makes session token cookies HTTPOnly (Does not afffect Ajax XMLHTTPRequest calls) 3. Makes cookies Session-Only (Non-persistent)

This solves three problems 1. Sessions token cookies are made SECURE (Only use this in SSL) 2. Makes session token cookies HTTPOnly (Does not afffect Ajax XMLHTTPRequest calls) 3. Makes cookies Session-Only (Non-persistent)

This solves three problems 1. Sessions token cookies are made SECURE (Only use this in SSL) 2. Makes session token cookies HTTPOnly (Does not afffect Ajax XMLHTTPRequest calls) 3. Makes cookies Session-Only (Non-persistent)

This solves three problems 1. Sessions token cookies are made SECURE (Only use this in SSL) 2. Makes session token cookies HTTPOnly (Does not afffect Ajax XMLHTTPRequest calls) 3. Makes cookies Session-Only (Non-persistent)

no notes exist for this slide