Information Systems 365/765Lecture 14 Application Security

November 8, 2016

Can your Architects & Developers Can your Architects & Developers Detect…Detect…

Buffer-overflows ?Parameter Tampering ?Stealth Commanding ?Cross-Site Scripting ?SQL Injection ?Cookie Poisoning ?Hidden Field Manipulation ?

If not, you are subject to…If not, you are subject to…

Crashing Servers/ApplicationsUser ImpersonationE-ShopliftingAccessing Sensitive DataTaking Control of Your Operating SystemTaking Control of Your Database

Why Is Application Security Why Is Application Security Important?Important?• New threats emerge every day

• Some hackers are not satisfied with penetrating your network; they seek information that resides in your applications/databases

• Applications are often plagued by poor designs, software bugs, and poor programming practices

• Applications may be a fast and easy entry point into a secure network

• Applications contain and process your most critical (important and sensitive) information

• Programming logic may cause vulnerabilities just as troublesome as difficulties inherent with certain technologies

Why Is Application Security Why Is Application Security Often Ignored?Often Ignored?

• Usually there are time and budget constraints in application development that cause proper testing and secure programming training to fall to the way-side

• Security is typically not prioritized by programming teams; they are paid to deliver functionality first and foremost

• E-commerce initiatives are often rushed into production• Organizations often expect the software manufacturer

“build in” security; security is 80% process driven, 20% software driven

Four Basic Security ConceptsFour Basic Security Concepts

Poor application security measures can lead to breaches in data:•Integrity•Confidentiality•Availability•Accountability

Securing the ApplicationSecuring the Application

• Authentication & Identification• Authorization & Access Control• Logging & Auditing Procedures• Managing User Sessions• Encryption Routines • And More…

Web Application SecurityWeb Application Security

The 9 Basic Rules

1. Validate Input and Output1. Validate Input and Output

All data input and output should be checked very carefully for appropriateness. This check should be to see if the data is what is expected (length, characters). Making a list of bad characters is not the way to go; the lists are rarely complete. A secure program should know what it expects, and reject other input. For example, if an input field is for a Social Security Number, then any data that is not a string of nine integers is not valid. A common mistake is to filter for specific strings or payloads in the belief specific problems can be prevented.

2. Fail Securely (Closed)2. Fail Securely (Closed)Applications should default to secure operation. That is, in the event of failure or misconfiguration, they should not reveal more information than necessary with regard to:

Error messages (for efficient debugging purposes) The application configuration (directory, version/patch

levels) The operating environment (network addressing, OS

version/patch levels)As well, they should not allow transactions or processes to continue

With more privileges than normal With more access than normal Without proper validation of input parameters and output

results Bypassing any monitoring or logging facilities

3. Keep it Simple3. Keep it Simple

While it is tempting to build elaborate and complex security controls, the reality is that if a security system is too complex for its user base, it will either not be used or users will try to find measures to bypass it. Often the most effective security is the simplest security. Do not expect users to enter 12 passwords.

4. Use and Reuse Trusted 4. Use and Reuse Trusted ComponentsComponents

Invariably other system designers (either on your development team or on the Internet) have faced the same problems as you. They may have invested a large amount of time on research and developing robust solutions to the problem. In many cases they will have improved components through an iterative process and learned from common mistakes along the way. Using and reusing trusted components make sense both from a resource stance and from a security stance. When someone else has proven they got it right; take advantage.

5. Defense in Depth5. Defense in Depth

Relying on one component to perform its function 100% of the time is unrealistic. While we hope to build software and hardware that works as planned, predicting the unexpected is difficult . Good systems don’t predict the unexpected, but plan for it. If one component fails to catch a security event, a second one would.

6. Only as Secure as the Weakest 6. Only as Secure as the Weakest LinkLink

We’ve all seen it, “This system is 100% secure, it uses 128 bit SSL”. While it may be true that the data in transit from the user’s browser to the web server has appropriate security controls, more often that not the focus of security mechanisms is at the wrong place. As in the real world where there is no point in placing all of your locks on your front door to leave the backdoor swinging in its hinges, you need to think carefully about what you are securing. Attackers are lazy and will find the weakest point and attempt to exploit it.

7. Security by Obscurity Won’t 7. Security by Obscurity Won’t Work in the Long RunWork in the Long Run

It’s naïve to think that hiding things from prying eyes doesn’t buy you some amount of time. Lets face it some of the biggest exploits unveiled in software have been obscured for years. But obscuring information is very different from protecting it. You are relying on the fact that no one stumbles onto your obfuscation. This strategy doesn’t work in the long term and has no guarantee of working in the short term.

8. Least Privilege8. Least Privilege

Systems should be designed in such a way that they run with the least amount of system privilege they need to do their job. This is the need to know approach. If a user account doesn’t need root privileges to operate, don’t assign them in the anticipation they may need them. Giving the pool man an unlimited bank account to buy the chemicals for your pool when you’re on vacation is unlikely to be a positive experience.

9. Compartmentalization9. Compartmentalization

Similarly compartmentalizing users, processes and data helps contain problems if they do occur. Compartmentalization is an important concept widely adopted in the information security realm. Imagine the same pool man scenario. Giving the pool man the keys to the house while you are away so he can get to the pool house, may not be a wise move. Containing his access to the pool house limits the types of problems that may occur if something was to happen.

Application SecurityApplication SecurityThe Top Ten ThreatsThe Top Ten Threats

http://www.owasp.orgDocumentation

The Guide The Top Ten

Software WebScarab WebGoat CodeSeeker Numerous Utilities – Check out the CVS tree

at Sourceforge.

Why OWASP?Why OWASP?

• Very competent team members• Producing Real World Results for

Administrators, Developers, and Security Testers alike. (maybe hackers too)

• Industry recognition.• U.S. Federal Government Recognition

The OWASP Top TenThe OWASP Top Ten

Unvalidated Input Broken Access Control Cross-Site Scripting Buffer Overflows Injection Flaws Improper Error

Handling Insecure Storage Denial of Service Insecure Configuration

Management

Unvalidated input originates Unvalidated input originates from:from:

Carry-over from the mainframe days – blindly trusting user input. This leads to:

“buffer-overflows” allowing execution of arbitrary code (e.g., Code Red)

“privilege escalation” becoming the administrator of the system

“impersonation” of other users

Best PracticesBest PracticesDefine What is allowedAs a rule don’t try to pick out everything that is not allowed.•Character Set ( UNICODE, UTF-8)•Input Length•Credit Card Format•Data Type (string, integer, etc)•Date•Numeric Range

Access ControlAccess ControlIdentification and authentication (I&A): These determine who can log on to a system.Authorization: This determines what an authorized user can do.Accountability: This identifies what a user did.

Basic Means of Identification & Basic Means of Identification & AuthenticationAuthentication

Authentication challengesThree means of authenticating a user’s identity•Something they know (Password)•Something they have (Phone)•Something they are (biometrics)Problems associated with each

Automated Password Reset Automated Password Reset SystemsSystems1. The user clicks on a “forgot my password” link

2. Ask the user to supply some details like personal details or ask a hint question.

3. Send an mail to the users authorized mail id with a link which will take the user to a page for resetting the password.

4. This link should be active for only a short time, and should be SSL- enabled.

5. The security benefits of this method are: the password is not sent in the mail; since the link is active for a short time, there is no harm

even if the mail remains in the mailbox for a long time.

Managing User Sessions – Session Management Managing User Sessions – Session Management SchemesSchemes

Session Time-Out Session tokens that do not expire on the HTTP server can allow an attacker

unlimited time to guess or brute force a valid authenticated session token. An example is the "Remember Me" option on many retail websites. If a user's cookie file is captured or brute-forced, then an attacker can use these static-session tokens to gain access to that user's web accounts. Additionally, session tokens can be potentially logged and cached in proxy servers that, if broken into by an attacker, may contain similar sorts of information in logs that can be exploited if the particular session has not been expired on the HTTP server.

Regeneration of Session Tokens To prevent Session Hijacking and Brute Force attacks from occurring to an

active session, the HTTP server can seamlessly expire and regenerate tokens to give attacker a smaller window of time for replay exploitation of each legitimate token. Token expiration can be performed based on number of requests or time.

Session Forging/Brute-Forcing Detection and/or Lockout Many websites have prohibitions against unrestrained password guessing

(e.g., it can temporarily lock the account or stop listening to the IP address).

Cross – Site ScriptingCross – Site Scripting

Hijacking/Breach of Trust. When hackers inject malicious code into a site, the false scripts are executed in a context that appears to have originated from the targeted site, giving attackers full access to the document retrieved, and maybe even sending data contained in the page back to the attacker.

Buffer OverflowsBuffer Overflows

Execution stack corruption of the web application leading to at a minimum a Denial of Service.

Execution stack corruption = unintentionally overwriting areas of memory in use by a process, with the intent of destroying important data.

What is SQL Injection?What is SQL Injection?

Inserting user-supplied SQL statements into a dynamically-generated SQL query making unintended use possible