This slide deck is a short survey presentation which at a very high and broad level, describes major issues of concern in application security.

1. Information Systems 365/765
Lecture 14 Application Security
November 8, 2016

2. Can your Architects & Developers Detect…Can your Architects & Developers Detect…
Buffer-overflows ?
Parameter Tampering ?
Stealth Commanding ?
Cross-Site Scripting ?
SQL Injection ?
Cookie Poisoning ?
Hidden Field Manipulation ?

3. If not, you are subject to…If not, you are subject to…
Crashing Servers/Applications
User Impersonation
E-Shoplifting
Accessing Sensitive Data
Taking Control of Your Operating System
Taking Control of Your Database

4. Why Is Application Security Important?Why Is Application Security 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

5. Why Is Application SecurityWhy 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

6. Four Basic Security ConceptsFour Basic Security Concepts
Poor application security measures can lead to
breaches in data:
•Integrity
•Confidentiality
•Availability
•Accountability

7. Securing the ApplicationSecuring the Application
• Authentication & Identification
• Authorization & Access Control
• Logging & Auditing Procedures
• Managing User Sessions
• Encryption Routines
• And More…

8. Web Application SecurityWeb Application Security
The 9 Basic Rules

9. 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.

10. 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

11. 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.

12. 4. Use and Reuse Trusted Components4. Use and Reuse Trusted Components
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.

13. 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.

14. 6. Only as Secure as the Weakest Link6. Only as Secure as the Weakest Link
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.

15. 7. Security by Obscurity Won’t Work in7. Security by Obscurity Won’t Work in
the Long Runthe 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.

16. 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.

17. 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.

18. Application SecurityApplication Security
The Top Ten ThreatsThe Top Ten Threats

19. http://www.owasp.org
Documentation
 The Guide
 The Top Ten
Software
 WebScarab
 WebGoat
 CodeSeeker
 Numerous Utilities – Check out the CVS tree at
Sourceforge.

20. 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

21. 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

22. Unvalidated input originates from:Unvalidated input originates 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

23. Best PracticesBest Practices
Define What is allowed
As 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

24. Access ControlAccess Control
Identification 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.

25. Basic Means of Identification &Basic Means of Identification &
AuthenticationAuthentication
Authentication challenges
Three means of authenticating a user’s identity
•Something they know (Password)
•Something they have (Phone)
•Something they are (biometrics)
Problems associated with each

26. Automated Password Reset SystemsAutomated Password Reset Systems
1. 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.

27. Managing User Sessions – Session Management SchemesManaging User Sessions – Session Management Schemes
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).

28. 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.

29. 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.

30. What is SQL Injection?What is SQL Injection?
Inserting user-supplied SQL statements into a
dynamically-generated SQL query making
unintended use possible