Coming up: Secure Web Applications

Secure EngineeringDan FleckCS 469: Security Engineering

Sources:https://www.owasp.org/index.php/OWASP_Guide_Project

11

Coming up: Development Methodology

Secure Web Applications

• OWASP Guide to Secure web applications• Security Standards (COBIT or ISO17799)• If you’re publicly traded in most countries, you must have an

information security policy • If you’re publicly traded in the US, you must have an information

security policy which is compliant with SOX requirements, which generally means COBIT controls

• If you’re privately held, but have more than a few employees or coders, you probably need one

• Popular FOSS projects, which are not typical organizations, should also have an information security policy

22

Coming up: Attackers

Development Methodology

Attributes to look for in a development methodology: • Strong acceptance of design, testing and documentation

• Places where security controls (such as threat risk analysis, peer reviews, code reviews, etc) can be slotted in

• Works for the organization’s size and maturity

• Has the potential to reduce the current error rate and improve developer productivity

3The choice of development methodology is not as important as simply having

one.

3

Coming up: Security Principles

Attackers

From most likely and damaging to least…

• Disgruntled staff or developers • “Drive by” attacks, such as side effects or direct consequences

of a virus, worm or Trojan attack • Motivated criminal attackers, such as organized crime • Criminal attackers without motive against your organization,

such as defacers • Script kiddies

44

Coming up: Minimize Attack Surface

Security Principles

• Minimize Attack Surface• Secure defaults• Principle of least privilege• Principle of defense in depth• Fail securely• External Systems are insecure• Separation of duties• Do not trust security through obscurity• Simplicity• Fix security issues correctly

55

Coming up: Secure Defaults

Minimize Attack Surface

• Every feature in your system adds to the attack surface• Reduce risk by reducing attack surface

• Example: Web application has inline help with a search function• May be vulnerable to SQL injection• Reduce: limit feature to authorized users• Reduce: use validation routines on input SQL• Eliminate: Re-write UI to eliminate need for search function!

• How to estimate the attack surface: https://www.owasp.org/index.php/Attack_Surface_Analysis_Cheat_Sheet 66

Coming up: Principle of Least Privilege

Secure Defaults

• Make the “out of the box” user experience good, but secure!

• Example:• default password aging ON• default password complexity ON

• Does your browser do this?• Does Facebook?• Why or why not?• Does Ubuntu? https://www.eff.org/deeplinks/2012/10/privacy-ubuntu-1210-amazon-ads-and-data-leaks

77

Coming up: Principle of Defense in Depth

Principle of Least Privilege

• Users (accounts) should have the least amount of privileges needed to do their job• Including: CPU limits, memory limits, network and file system

permissions

• Example: If a middleware server only requires network access, ability to read the DB and ability to write to log files, that is ALL it should be able to do!

88

Coming up: Fail securely

Principle of Defense in Depth

• Controlling defense by using multiple, different, independent approaches is always preferable

• Layers of defenses good when possible

• Example: Flawed user admin interface harder to exploit if it correctly gates access to production management networks (isolation), checks for user authorization, and logs all access

• Example: How do you protect your computer?

9Anti-virus, usernames/passwords, IDS, firewall, encryption of important files, biometrics(?)

9

Coming up: External systems are insecure

Fail securely

• When failing, fail into a secure state

isAdmin = true; try {

codeWhichMayFail();isAdmin = isUserInRole( “Administrator” );

}catch (Exception ex) {

log.write(ex.toString()); }

10Secure or not secure? 10

Coming up: Separation of duties

External systems are insecure

• If your system uses a third party system, assume it’s not as secure as you.

• They have different constraints, different motivations, etc…

• Check all data they send. Assume it’s not trusted.

1111

Coming up: Do not trust security through obscurity

Separation of duties

• Make sure multiple users are needed to perform secure tasks.

• Typically, administrators have special privileges, so they should NOT be users also.

• Example: An admin can turn the system on/off and change the password policies. Thus, they should not have access to login to the system as a privileged user to buy items on behalf of users.

1212

Coming up: Simplicity

Do not trust security through obscurity

• Security should be reliant on keeping secrets

• Obscurity is a weak control and almost always fails when it’s the only one in place. You can use it, but NOT as the only idea.

• Example: security of an application should NOT be reliant on keeping the source secret. Does this happen?

• What’s more secure, Windows or Linux? Why do you think? What about Android vs iOS?

1313

Coming up: Fix security issues correctly

Simplicity

• Generally, simplicity helps reduce attack surface

• Complex approaches frequently cause holes and frequently are only in place to handle “future” expansion that may never happen.

• Code is done when it works… stop coding! (This is also a software engineering principle)

1414

Coming up: Threat Risk Modeling and Objectives

Fix security issues correctly

• When security issues are found, check all places they may be.

• Specifically, if found in common code or design patterns being used the same code problem may be in multiple places

• Example: A user finds by manipulating cookies they can view another user’s balance. Fixing the problem is simple, but the same cookie handling code may be in multiple other places within the application

1515

Coming up: Document Threats

Threat Risk Modeling and Objectives

16

Identity: does this application protect user’s identity from misuse? Reputation: the loss of reputation derived from the application being misused or successfully attacked

Financial: the level of risk the organization is prepared to stake in remediation potential financial loss.

Privacy and regulatory: to what extent shall applications protect user’s data. Forum software is by its nature public, but a tax program is inherently bound up in tax regulation and privacy legislation in most countries

Availability guarantees: is this software required to be available by SLA or similar agreement? Is it nationally protected infrastructure? To what level will the application need to be available?

16

Coming up: Lots of “threat modeling” templates out there

Document Threats

• Sample threat graph

1717

Coming up: Phishing

Lots of “threat modeling” templates out there• STRIDE:• Spoofing identity• Tampering with data• Repudiation• Information disclosure• Denial of service• Elevation of privileges

• There are others though (CVSS, OCTAVE, AS/NZS…)

1818

Coming up: Countering Phishing

Phishing• 5% of users are lured into these attacks! [2005]

• 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 believable form that asks the users for their 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...

1919

Coming up: Countering Phishing when using email

Countering Phishing

• Some technical approaches • sanitizing email attachments• anti-adware, malware

• Best approach: user education

2020

Coming up: Countering Phishing when using email (cont)

Countering Phishing when using email

• Tell users every single time you communicate with them, that: • they must type your URL into their browser to access your site • you don’t provide links for them to click • you will never ask them for their secrets • and if they receive any such messages, they should immediately

report any such e-mail to you, and you will forward that on to their local law enforcement agencies

• Consistent branding – don’t send e-mail that references another company or domain.

• Reduce Risk - don’t send e-mail at all. • Reduce Risk - don’t send HTML e-mail. 2121

Coming up: Countering Phishing when using email (cont)

Countering Phishing when using email (cont)• Reduce Risk - be careful of using “short” obfuscated URLs (like

http://redir.example.com/f45jgk)

• Increase trust - Many large organizations outsource customer communications to third parties. Work with these organizations to make all e-mail communications appear to come from your organization (i.e., crm.example.com where example.com is your domain, rather than smtp34.massmailer.com or even worse, just an IP address).

• Increase trust - set up a Sender Policy Framework (SPF) record in your DNS to validate your SMTP servers. Phishing e-mails not sent from servers listed in your SPF records will be rejected by SPF aware MTAs.

2222

Coming up: Customer Relations

Countering Phishing when using email (cont)• Increase trust – sign email

• Incident Response - Don’t send users e-mail notification that their account has been locked or fraud has occurred – if that has happened, just lock their accounts and provide a telephone number or e-mail address for them to contact you (or even better, ring the user)

2323

Coming up: Website Design

Website Guidelines

• Never ask customers for their secrets

• Fix XSS issues

• Don’t use pop-ups. They confuse people and make it easier for attackers

• Don’t use frames – attackers can re-use them

• Enforce local referrers for images and other resource – this forces attackers to copy them, and possibly mess them up or forget to update when you change them

Investigate any connections that just pull images2424

Coming up: Safeguards

Website Guidelines (cont)

• Don’t be the source of identity theft – If you maintain information about the users, don’t present this data to users.

• Example: Internet Banking solutions may allow users to update their physical address records. There is no point in displaying the current address within the application, so the Internet Banking solution’s database doesn’t need to hold address data – only back end systems do.

2525

Coming up: Safeguards

Safeguards to limit exposure

• If an account is opened, but not used for a period of time (say a week or a month), disable it.

• Verify the registration info. Example: does the ZIP code mean California, but the phone number come from New York?

• Daily limits, particularly for unverified customers. • Settlement periods for offsite transactions to allow users time

to repudiate transactions. • Only deliver goods to the customer’s home country and

address as per their billing information • Only deliver goods to verified customers (or consider a limit

for such transactions). 2626

Coming up: Monitor Unusual Activity

Safeguards to limit exposure (cont)• If your application allows updates to e-mail addresses or

physical addresses, send a notification to both the new and old addresses when the key contact details change.

• Do not send existing or permanent passwords via e-mails or physical mail. Use one time, time limited verifiers instead.

• Implement SMS or e-mail notification of account activities, particularly those involving transfers and change of address or phone details.

• Prevent too many transactions from the same user being performed in a certain period of time – this slows down automated attacks.

• Two factor authentication for highly sensitive or high value transactional accounts.

2727

Coming up: Other things…

Monitor Unusual Activity

• Example: Clearing out their accounts

• What are some others for a banking application?• What about a web commerce app?

2828

Coming up: Other things…

Other things…• There are more things to do… secure standards• Network security• Secure coding• Cryptography• (all the things we discussed in the semester! )

• etc, etc… always learn, always research best practices

• https://www.owasp.org/index.php/Cheat_Sheets• https://www.owasp.org/index.php/

Category:OWASP_Application_Security_Verification_Standard_Project

29All of us are smarter than any of us(but don’t apply this during exams )

29

End of presentation

3030