Microsoft TechEd Asia 2005

1
Security Risks beyond the Network Developing
Secure Solutions
Jeff Zado jzado_at_microsoft.com Sr. Product
Manager Development Tools Microsoft Canada
2
Abstract

• Ensuring that your organizations applications
  are secure is no longer just about firewalls,
  networks and simple authentication. Security is a
  big challenge for organizations and the price of
  failure could mean disastrous results for
  companies and shareholders. But I am sure that
  you all know this, as you are security experts.
  However, developing secure software is a
  relatively new discipline that organizations are
  adopting and integrating throughout the software
  development lifecycle. In this talk we will look
  at common application security issues, how
  companies can identify them earlier in the
  development lifecycle and how Microsoft solutions
  can be leveraged to assist you and our
  organizations.

3

• We cannot adopt the way of living that was
  satisfactory a hundred years ago. The world in
  which we live has changed, and we must change
  with it.
• Felix Adler

4
State of the Industry
Over 70 percent of security vulnerabilities
exist at the application layer, not the network
layer Gartner
The battle between hackers and security
professionals has moved from the network layer to
the Web applications themselves Network World
64 percent of developers are not confident in
their ability to write secure applications Micros
oft Developer Research
Hacking has moved from a hobbyist pursuit with a
goal of notoriety to a criminal pursuit with a
goal of money Counterpane Internet Security
5
Security BreachesAffecting Businesses and
Consumers
6

• The FTC reports 1,000 cases a day of ID theft
• A recent FBI operation put an end to a scheme in
  which nearly 150,000 victims lost more than 215
  million
• The number of phishing e-mail messages
  intercepted by a prominent web security company
  grew 300 since June 2004
• Over 80 of the top 100 financial institutions
  have reported external attacks on their IT
  systems in the past year

7
June 23, 2006 Another Government Security Breach

• "There ought to be an assumption that data is
  encrypted when it is at rest or in transit,"
  Kurtz said. "With encryption, a stolen laptop is
  simply a stolen laptop."

8
Elements that Drive Change
People Providing guidance on secure application
development
Process Security cannot be an afterthought
Tools Providing the most innovative tools
9
People Education as a Driver
Patterns Practices Dedicated team focused on
security guidance
MSDN and TechNet Sharing whitepapers and how tos
Education Train every Developer and IT
Professional on security
10
Process Security Development Lifecycle (SDL)
A PROCESS by which Microsoft develops software
and defines security requirements and milestones

• Reduce the number of security errors
• Reduce the severity of any security errors not
  found
• Reduce the attack surface

11
Accountability and Incentives

• Microsoft Developer Research Almost 40 percent
  of developers say that their companies do not
  think it is very important to write secure
  applications
• CXOs and management say it is very important
• Current incentives on performance and ship dates
• Must be driven top-down

12
Engineering ExcellenceFocus Yielding Results
13
Tools Utilizing Innovation
Tools facilitate creating secure applications
Secure by Default
Static Analysis
Create non-admin apps
Scan your code for security vulnerabilities
Secure Software Development Lifecycle Process
Seamless create applications for a custom zone
Nurturing the Partner Ecosystem
14
Canadian Events and Expertise

• MSDN, Technet and Security Events and web
  resources
• Threat Modeling http//msdn.microsoft.com/securit
  y/securecode/threatmodeling/acetm/video/

15
Consequences of Inappropriate Input Handling

• Lead to a realization of various attack patterns
• Cross-Site Scripting (XSS)
• One-Click Attacks
• SQL Injection
• Canonicalization issues
• Buffer overflow or arithmetic errors (Memory
  Management issues)
• Denial of Service

16
What is Cross-Site Scripting?

• A technique that allows attackers to
• Appear to rewrite the text of your web site
• Abuse the users trust in your website to
• Steal Web session information and cookies
• Hijack client sessions
• Potentially access the client computer

17
Defending Against Cross-Site Scripting Attacks

• Do not
• Trust user input
• Echo client-supplied data without encoding
• Store secret information in cookies
• Do
• Take advantage of ASP.NETs RequestValidation
• Take advantage of ASP.NETs ViewStateUserKey
• Consider IOSec for data encoding
  (http//toolbox/details/details.aspx?ToolID22241)
  
• Use the HttpOnly cookie option
• Use the ltframegt security attribute

18
What is One-Click Attack?

• Site offers persistent sign-in option (cookies)
• Victim user navigates to (or opens) an HTML page
  perhaps a once in a lifetime offer
• One or more actions are carried out using the
  trust of the victim user which is completely
  unsuspecting to that user

19
Defending Against One-Click Attack

• Browsers cross-frame security limits this to a
  write-only attack
• Concept for defense require a data element in
  the request which the attacker cant supply
• (Overkill) Re-authenticate the user
• Can ask for confirmation
• Check Referrer field
• document.location or window.open() dont post
  Referrer

20
Defending Against One-Click Attack (cont.)

• Classic ASP
• Generate a unique session ID once user
  authenticates, encrypt it and bind it to each
  response sent to user
• In .Net 1.1 use ViewStateUserKey
• Value assigned to it must be unique to the
  current user
• This value is used as a factor in the ViewState
  MAC

override protected void OnInit(EventArgs e) //
... ViewStateUserKey User.Identity.Name //
...
21
What is SQL Injection?

• SQL injection is
• The process supplying carefully crafted input to
  alter (or create) SQL statements
• Can be used by malicious users to compromise
  confidentiality, integrity or availability of
  your application
• Probe databases
• Bypass authorization
• Execute multiple SQL statements
• Call built-in stored procedures

22
Defending Against SQL Injection

• Abandon Dynamic SQL
• Use stored procedures or SQL parameterized
  queries to access data
• Can have SQL Injection in stored procedures
• Sanitize all input
• Consider all input harmful until proven otherwise
  test for valid data and reject everything else
• Run with least privilege
• Never execute as sa
• Restrict access to built-in stored procedures
• Do not display ODBC errors

23
What are Memory Management Issues

• Buffer Overrun
• Exists primarily in unmanaged (C/C) code
• Can lead to a host-level exploits keep your
  host patched and up-to-date
• Arithmetic Errors

24
What are Arithmetic Errors

• Occur when the limitations of a variable are
  exceeded
• E.g., Assign the value 300 to a byte
• Lead to serious runtime issues
• Are often overlooked and underestimated
• Include
• Overflow value too large for data type
• Underflow value too small for data type

25
Logging

• Application Security is more then setting up
  perimeter defense
• Keep a log trail of authentication attempts
• Both successful and failed
• Keep a log trail of all accesses to assets
• Log as close to an asset as possible
• SQL Server Stored Procedure
• Sometimes a log trail is the only mitigation
• Identify who, what, where when

26
What you Log

• Fire and Forget Asynchronous logging
• MSMQ
• Dont write sensitive information in logs
• Passwords
• Identify the (who, what, where when)
• Identity
• Action
• Component/Service/Object/Method
• Timestamp

27
Audit

• Logs identify the who, what, where when
• Audit the logs to determine why
• Setup a process whereby logs are audited
• Monitor Response Process
• Can be automated to some extent
• Log files are an asset!

28
A (Quick) Summary

• Use existing technologies that meet your needs
• But implement appropriately!
• Think cynical dont trust outside sources
• Application users
• External dependencies