Azure Security Notes
|
|
- Dina Gordon
- 8 years ago
- Views:
Transcription
1 Azure Security Notes Lessons Learned from Exploring Microsoft Azure and the Cloud Security Space J.D. Meier, Principal PM, Microsoft Paul Enfield
2 Acknowledgments Thanks to the following external contributors and reviewers: Adam Grocholski; Andy Eunson; Bill Collette; Christopher Seary; Jason Taylor; John Daniels; Juval Lowy; Kevin Lam; Long Le; Michael Smith; Michael Stiefel; Michele Leroux Bustamante; Norman Headlam; Rockford Lhotka; Rudolph Araujo; Sarang Kulkarni; Steven Nagy; Terrance Snyder; Will Clevenger Thanks to the following Microsoft contributors and reviewers: Akshay Aggarwal; Alik Levin; Andreas Fuchsberger; Babur Butter; Bharat Shyam; Dave Brankin; Danny Cohen; Diego Dagum; Don Willits; Eugenio Pace; Gabriel Morgan; Jeff Mueller; John Steer; Julian Gonzalez; Mark Curphey; Mohit Srivastava; Pat Filoteo; Rahul Verma; Raul Rojas; Scott Densmore; Sesha Mani; Serena Yeoh; Sriram Krishnan; Stefan Schackow; Steve Marx; Stuart Kwan; Terri Schmidt; Tobin Titus; Varun Sharma; Vidya Vrat Agarwal; Vikram Bhambri; Yale Li
3 Our Cloud Security Approach Objectives Learn a security frame Learn an approach for applying the security frame to application scenarios Learn key components of the security approach for these notes Overview These notes summarize how we took a look at securing Web applications, web services, and data in the cloud. We basically started by mapping out common application scenarios. We then figured out a way to group threats and attacks into a set of common categories. These categories make it easy for us to analyze and inspect the various parts of an application and engineering decisions. Then we focused on finding common principles, patterns, and practices, while working with customers, field, product teams, and industry experts. Our Cloud Security Approach in a Nutshell We took a pragmatic approach to security, identifying key deltas, building on what we know, and leveraging proven practices. Here are some of the cornerstone concepts we used to focus and drive our security efforts: Visual Application Scenarios and Solutions. We created simple visuals that show end-toend scenarios. You can think of these as how you might put on a whiteboard if you were to draw the end in mind for a particular application scenario. This is a simple way to share authentication and authorization patterns for common application scenarios. Secure the network, host, and application. Ask any security expert, where the problems are, and they ll say it s the stuff that falls between the cracks. Thinking about security holistically across the network, host, and application is the key to both helping you focus your efforts, as well as catching what falls between the cracks. Principles, patterns, and practices. Design principles help you leverage proven practices. Rather than have a rule for everything, you have a smaller set of principles to guide you. Patterns are simply problem and solution pairs in context. They help share strategies and principles by building a shared vocabulary. For example, the Trusted Subsystem pattern encapsulates the idea of trusting the application identity rather than every caller. Practices are simply actions, methods, or techniques. For example, you can use patterns & practices Threat Modeling to shape the security design of your application. Threats and countermeasures. One way to make security actionable and prescriptive is to focus on threats and countermeasures. This means identifying the bad things that can happen, and what your defenses, security controls, or countermeasures are.
4 Security Frame. There are many ways to chunk up and think about security. For example, you might use C.I.A., where C is confidentiality, I is integrity, and A represent availability. Another approach is to focus on the three A s: Authentication, Access control, and Auditing. We ve found it especially useful to use the following categories to organize and share application security principles, patterns, anti-patterns, and practices: Auditing and Logging, Authentication, Authorization, Communication, Configuration Management, Cryptography, Exception Management, Sensitive Data, Session Management, and Validation. People, process, and technology. Another way to look at security is through the people, process, and technology viewpoints. You can also use each of these views when you look at security for your network, host, and application. Application, Infrastructure, and Business. This is another helpful lens for looking at security. You can look at the principles, patterns, and practices for the application, the infrastructure, or the business. This leads to application security patterns, infrastructure security patterns, and business security patterns and practices. At the end of the day, what s important is using the lens that helps you the most, and avoid using the wrong tool for the job, or using a one-size fits all solution. Instead, chunk up the problem, while keeping a holistic view. How We Got Started Tackling cloud security can be overwhelming without an approach. In these notes, we have an approach that simplifies and improves security. It does so by chunking up security in a way that helps us leverage proven practices, while sharing information around emerging practices. One way to simplify thinking about security is to simplify the language. When we first started talking with customers about the cloud and security, it was difficult to have meaningful conversations, simply because we didn t have a shared vocabulary. Using a threats and countermeasures approach to talk about security is a key step to simplifying cloud security. Basically, we can look through our security lens (our security frame), and look for threats, attacks, vulnerabilities, and countermeasures. We can use that same lens and look for principles, patterns, and anti-patterns. This helps us turn security information into insight and action. Another important step is leveraging application types from the patterns & practices Application Architecture Guide, second edition - Rather than focus on queues and worker roles, we can shift our focus to application scenarios, and represent them visually. Our goal is to show how to secure your Web application, Web services, and data in the cloud visually. With these scenarios we can move to the whiteboard and draw end-to-end scenarios.
5 By using a security frame, focusing on threats and countermeasures, and visual scenarios, we have an effective backdrop for analyzing, evaluating, and talking about cloud security challenges. Threats and Countermeasures Focus One way to make security actionable and prescriptive is to focus on threats, attacks, vulnerabilities and countermeasures: Threat - A potential occurrence malicious or otherwise that may harm an asset. Attack - An action taken to harm an asset. Vulnerability - A weakness that makes a threat possible. Countermeasure - A safeguard that addresses a threat and mitigates risk. This means identifying the bad things that can happen, and what your defenses, security controls, or countermeasures are. By building a knowledgebase of threats, attacks, vulnerabilities, and countermeasures, we can dramatically improve our ability to share security know-how. Example Application Scenario and Solution Each Visual Scenario and Solution consists of a Scenario, Solution, and Solution Summary Table. The Scenario is a simple visual of the application from a deployment standpoint. The Solution is a visual of how you might address authentication, authorization, and communication (the security runtime patterns.) The Solution Summary Table is a quick description of how you would address the authentication, authorization, and communication from a security standpoint. Scenario
6 Solution Solution Summary Table Area Notes Authentication Authenticate users with forms authentication Store users in Azure Tables Use TableStorageMembershipProvider for membership API s Authenticate application against Azure Storage with access key Map ASP.NET users to single Azure Storage connection All access to the database occurs as the application identity Authorization Use TableStorageRoleProvider for roles API s Authorize users in application logic Store roles in Azure Tables Communication Use HTTP port 80 for non-secure connections to ASP.NET application Perform forms authentication over port 443 (SSL) Security Frame A Security Frame acts as a simple lens. It helps organize and share security knowledge in a set of actionable buckets. Here is an explanation of the key buckets used in these notes: Category Auditing and Logging Authentication Authorization Communication Configuration Management Cryptography Exception Management Sensitive Data Notes How security-related events are recorded, monitored, and audited. The process of proving identity, typically through credentials, such as a user name and password How your application provides access controls for roles, resources and operations. How data is transmitted over the wire. Transport security versus message encryption is covered here. How your application handles configuration and administration of your applications from a security perspective. How your application enforces confidentiality and integrity. How you handle applications errors and exceptions. How your application handles any data that must be protected either in
7 Session Management Validation memory, over the network, or in persistent stores A session refers to a series of related interactions between a user and your application. How your application filters, scrubs, or rejects input before additional processing, or how it sanitizes output. The key to the buckets is that they are actionable. Another key is that developers can relate to them. This makes it easier to share security knowledge between security experts and developers in a pragmatic way. Carrying the Story Forward Improving Web Application Security: Threats and Countermeasures ( illustrates the approach of securing a solution by addressing key security hotspots defined by the security frame in Figure 1 below. This visual model allows you to conceptualize specific areas and items in an architecture that need to be addressed during the process of securing an application. The visual model represents a fairly typical on-premise application architecture, and then pins hotspots against it. Securing the Application Auditing and Logging Authentication Authorization Configuration Mgt. Cryptography Exception Management Parameter Manipulation Sensitive Data Session Management Validation Web Server Application Server Database Server Firewall Apps Host Firewall Apps Host Database Host Securing the Network Router Firewall Switch Patches and Updates Services Protocols Securing the Host Accounts Files and Directories Shares Ports Registry Auditing and Logging Threats and Countermeasures Figure 1. Securing the Network, Host and Application On-premise Using this visual model concept and the revised security frame for cloud applications we can use the same approach to evaluate cloud applications. In Figure 2 below, we modify the visual
8 model by hosting both the application and data layers in the managed infrastructure, which in this case is the cloud. With a managed infrastructure we can remove checks from our list because they are items handled by the managed infrastructure. For example, a Windows Azure application will not have permissions to create user accounts, or elevate privileges. This alleviates the need to manage accounts at the host level. Securing the Application Auditing and Logging Authentication Authorization Communication Configuration Management Cryptography Exception Management Sensitive Data Session Management Validation Application Layer Database Layer Firewall Apps Cloud Host Data Managed Infrastructure Securing the Network Router Firewall Switch Securing the Host Patches and Updates Accounts Services Files and Directories Protocols Shares Ports Registry Auditing and Logging Threats and Countermeasures Figure 2. Securing the Network, Host and Application in the Cloud The above diagram represents the canonical case architecture. To evaluate other architectures such as ones involving federated identity or hybrid on-premise and cloud implementations, you can use the same approach. Represent your architecture with a base diagram, and overlay the frame on it. Once the frame is overlaid, you can evaluate each item for applicability and quickly scope out categories not needing attention.
9 Cloud Security Threats and Countermeasures Objectives Learn a security frame that applies to the cloud. Learn top threats/attacks, vulnerabilities and countermeasures for each area within the security frame. Understand differences between threats, attacks, vulnerabilities and countermeasures. Overview It is important to think like an attacker when designing and implementing an application. Putting yourself in the attacker s mindset will make you more effective at designing mitigations for vulnerabilities and coding defensively. This section is a reference of the security frame, and its pieces pinned against the cloud as a platform. We also present threats, vulnerabilities and countermeasures against the cloud organized by hot spot such that you can see how they relate to each other in each category. Threats, Attacks, Vulnerabilities, and Countermeasures This chapter analyzes security from the perspectives of threats, vulnerabilities, attacks, and countermeasures against the cloud. These terms are defined as follows: Asset. A resource of value such as the data in a database, data on the file system, or a system resource. Threat. A potential occurrence malicious or otherwise that can harm an asset. Vulnerability. A weakness that makes a threat possible. Attack. An action taken to exploit vulnerability and realize a threat. Countermeasure. A safeguard that addresses a threat and mitigates risk. Cloud Security Frame The following key security concepts provide a frame for thinking about security when designing and architecting Windows Azure applications. Understanding these concepts helps you put core security features such as authentication, authorization, auditing, confidentiality, integrity, and availability in action. Hot Spot Auditing and Logging Authentication Description Auditing and logging in Windows Azure refers to how security-related events are recorded, monitored, audited, exposed, compiled & partitioned across multiple cloud instances. Examples include: Who did what and when and on which VM instance? Authentication is the process of proving identity, typically through credentials, such as a user name and password. In the cloud this also encompasses
10 Authorization Communication Configuration Management Cryptography Input and Data Validation Exception Management Sensitive Data authentication against varying identity stores. Authorization in Windows Azure is how your application provides access controls for roles, resources and operations. Authorization strategies might involve standard mechanisms, utilize claims and potentially support a federated model. Communication encompasses how data is transmitted over the wire. Transport security, message encryption, and point to point communication are covered here. Configuration management refers to how your application handles configuration and administration of your applications from a security perspective. Examples include: Who does your application run as? Which databases does it connect to? How is your application administered? How are these settings secured? Cryptography in Windows Azure refers to how your application enforces confidentiality and integrity. Examples include: How are you keeping secrets (confidentiality)? How are you tamper-proofing your data or libraries (integrity)? How are you providing seeds for random values that must be cryptographically strong? Certificates and cert management are in this domain as well. Validation refers to how your application filters, scrubs, or rejects input before additional processing, or how it sanitizes output. It's about constraining input through entry points and encoding output through exit points. Message validation refers to how you verify the message payload against schema, as well as message size, content and character sets. Examples include: How do you know that the input your application receives is valid and safe? Do you trust data from sources such as databases and file shares? Exception management refers to how you handle applications errors and exceptions. Examples include: When your application fails, what does your application do? Does it support graceful failover to other application instances in the cloud? How much information do you reveal? Do you return friendly error information to end users? Do you pass valuable exception information back to the caller? Sensitive data refers to how your application handles any data that must be protected either in memory, over the network, or in persistent stores. Examples include: How does your application handle sensitive data? How is sensitive data shared between application instances? Threats and Attacks Category Auditing and Logging Items Disclosure of confidential information. An attacker gathers sensitive information from log files. Denial of service (DoS). An attacker overwhelms logs with excessive entries or very large log entries.
11 Repudiation. An attacker denies performing an operation, exploits an application without trace, or covers his or her tracks. Authentication Network eavesdropping. An attacker steals identity and/or credentials off the network by reading network traffic not intended for them. Brute force attacks. An attacker guesses identity and/or credentials through the use of brute force. Dictionary attacks. An attacker guesses identity and/or credentials through the use of common terms in a dictionary designed for that purpose. Cookie replay attacks. An attacker gains access to an authenticated session through the reuse of a stolen cookie containing session information. Credential theft. An attacker gains access to credentials through data theft; for instance, phishing or social engineering. Authorization Elevation of privilege. An attacker enters a system as a lower-level user, but is able to obtain higher-level access. Disclosure of confidential data. An attacker accesses confidential information because of authorization failure on a resource or operation. Data tampering. An attacker modifies sensitive data because of authorization failure on a resource or operation. Luring attacks. An attacker lures a higher-privileged user into taking an action on their behalf. This is not an authorization failure but rather a failure of the system to properly inform the user. Token stealing. An attacker steals the credentials or token of another user in order to gain authorization to resources or operations they would not otherwise be able to access. Communication Failure to encrypt messages. An attacker is able to read message content off the network because it is not encrypted. Theft of encryption keys. An attacker is able to decrypt sensitive data because he or she has the keys. Man-in-the-middle attack. An attacker can read and then modify messages between the client and the service. Session replay. An attacker steals messages off the network and replays them in order to steal a user's session. Data tampering. An attacker modifies the data in a message in order to attack the client or the service Configuration Management Unauthorized access to configuration stores. An attacker gains access to configuration files and is able to modify binding settings, etc. Retrieval of clear text configuration secrets. An attacker gains access to configuration files and is able to retrieve sensitive information such as database connection strings. Cryptography Encryption cracking. Breaking an encryption algorithm and gaining access to the encrypted data. Loss of decryption keys. Obtaining decryption keys and using them to access protected data. Exception Management Information disclosure. Sensitive system or application details are revealed through exception information. Denial of service. An attacker uses error conditions to stop your service or place it in an unrecoverable error state.
12 Elevation of privilege. Your service encounters an error and fails to an insecure state; for instance, failing to revert impersonation. Input and Data Validation Canonicalization attacks. Canonicalization attacks can occur anytime validation is performed on a different form of the input than that which is used for later processing. For instance, a validation check may be performed on an encoded string, which is later decoded and used as a file path or URL. Cross-site scripting. Cross-site scripting can occur if you fail to encode user input before echoing back to a client that will render it as HTML. SQL injection. Failure to validate input can result in SQL injection if the input is used to construct a SQL statement, or if it will modify the construction of a SQL statement in some way. Cross-Site Request Forgery: CSRF attacks involve forged transactions submitted to a site on behalf of another party. XPath injection. XPath injection can result if the input sent to the Web service is used to influence or construct an XPath statement. The input can also introduce unintended results if the XPath statement is used by the Web service as part of some larger operation, such as applying an XQuery or an XSLT transformation to an XML document. XML bomb. XML bomb attacks occur when specific, small XML messages are parsed by a service resulting in data that feeds on itself and grows exponentially. An attacker sends an XML bomb with the intent of overwhelming a Web service s XML parser and resulting in a denial of service attack. Sensitive Data Memory dumping. An attacker is able to read sensitive data out of memory or from local files. Network eavesdropping. An attacker sniffs unencrypted sensitive data off the network. Configuration file sniffing. An attacker steals sensitive information, such as connection strings, out of configuration files. Vulnerabilities Category Items Auditing and Failing to audit failed logons. Logging Failing to secure log files. Storing sensitive information in log files. Failing to audit across application tiers. Failure to throttle log files. Authentication Using weak passwords. Storing clear text credentials in configuration files. Passing clear text credentials over the network. Permitting prolonged session lifetime. Mixing personalization with authentication. Using weak authentication mechanisms (e.g., using basic authentication over
13 an untrusted network). Authorization Relying on a single gatekeeper (e.g., relying on client-side validation only). Failing to lock down system resources against application identities. Failing to limit database access to specified stored procedures. Using inadequate separation of privileges. Connection pooling. Permitting overprivileged accounts. Configuration Management Using insecure custom administration interfaces. Failing to secure configuration files on the server. Storing sensitive information in the clear text. Having too many administrators. Using overprivileged process accounts and service accounts. Communication Not encrypting messages. Using custom cryptography. Distributing keys insecurely. Managing or storing keys insecurely. Failure to use a mechanism to detect message replays. Not using either message or transport security. Cryptography Using custom cryptography Failing to secure encryption keys Using the wrong algorithm or a key size that is too small Using the same key for a prolonged period of time Distributing keys in an insecure manner Exception Management Input and Data Validation Failure to use structured exception handling (try/catch). Revealing too much information to the client. Failure to specify fault contracts with the client. Failure to use a global exception handler. Using non-validated input used to generate SQL queries. Relying only on client-side validation. Using input file names, URLs, or usernames for security decisions. Using application-only filters for malicious input. Looking for known bad patterns of input. Trusting data read from databases, file shares, and other network resources. Failing to validate input from all sources including cookies, headers, parameters, databases, and network resources. Sensitive Data Storing secrets when you do not need to. Storing secrets in code. Storing secrets in clear text in files, registry, or configuration. Passing sensitive data in clear text over networks. Countermeasures Category Items
14 Auditing and Logging Identify malicious behavior. Know your baseline (know what good traffic looks like). Use application instrumentation to expose behavior that can be monitored. Throttle logging. Strip sensitive data before logging. Authentication Use strong password policies. Do not store credentials in an insecure manner. Use authentication mechanisms that do not require clear text credentials to be passed over the network. Encrypt communication channels to secure authentication tokens. Use Secure HTTP (HTTPS) only with forms authentication cookies. Separate anonymous from authenticated pages. Using cryptographic random number generators to generate session IDs. Authorization Use least-privileged accounts. Tie authentication to authorization on the same tier. Consider granularity of access. Enforce separation of privileges. Use multiple gatekeepers. Secure system resources against system identities. Configuration Management Using insecure custom administration interfaces. Failing to secure configuration files on the server. Storing sensitive information in the clear text. Having too many administrators. Using overprivileged process accounts and service accounts. Communication Use message security or transport security to encrypt your messages. Use proven platform-provided cryptography. Periodically change your keys. Use any platform-provided replay detection features. Consider creating custom code if the platform does not provide a detection mechanism. Turn on message or transport security. Cryptography Do not develop and use proprietary algorithms (XOR is not encryption. Use established cryptography such as RSA) Avoid key management. Use the RNGCryptoServiceProvider method to generate random numbers Periodically change your keys Exception Management Use structured exception handling (by using try/catch blocks). Catch and wrap exceptions only if the operation adds value/information. Do not reveal sensitive system or application information. Implement a global exception handler. Do not log private data such as passwords. Sensitive Data Do not store secrets in software. Encrypt sensitive data over the network. Secure the channel. Encrypt sensitive data in configuration files. Validation Do not trust client input.
15 Validate input: length, range, format, and type. Validate XML streams. Constrain, reject, and sanitize input. Encode output. Restrict the size, length, and depth of parsed XML messages. Threats and Attacks Explained 1. Brute force attacks. Attacks that use the raw computer processing power to try different permutations of any variable that could expose a security hole. For example, if an attacker knew that access required an 8-character username and a 10-character password, the attacker could iterate through every possible (256 multiplied by itself 18 times) combination in order to attempt to gain access to a system. No intelligence is used to filter or shape for likely combinations. 2. Buffer overflows. The maximum size of a given variable (string or otherwise) is exceeded, forcing unintended program processing. In this case, the attacker uses this behavior to cause insertion and execution of code in such a way that the attacker gains control of the program in which the buffer overflow occurs. Depending on the program s privileges, the seriousness of the security breach will vary. 3. Canonicalization attacks. There are multiple ways to access the same object and an attacker uses a method to bypass any security measures instituted on the primary intended methods of access. Often, the unintended methods of access can be less secure deprecated methods kept for backward compatibility. 4. Cookie manipulation. Through various methods, an attacker will alter the cookies stored in the browser. Attackers will then use the cookie to fraudulently authenticate themselves to a service or Web site. 5. Cookie replay attacks. Reusing a previously valid cookie to deceive the server into believing that a previously authenticated session is still in progress and valid. 6. Credential theft. Stealing the verification part of an authentication pair (identity + credentials = authentication). Passwords are a common credential. 7. Cross-Site Request Forgery (CSRF). Interacting with a web site on behalf of another user to perform malicious actions. A site that assumes all requests it receives are intentional is vulnerable to a forged request. 8. Cross-site scripting (XSS). An attacker is able to inject executable code (script) into a stream of data that will be rendered in a browser. The code will be executed in the context of the user s current session and will gain privileges to the site and information that it would not otherwise have. 9. Connection pooling. The practice of creating and then reusing a connection resource as a performance optimization. In a security context, this can result in either the client or server using a connection previously used by a highly privileged user being used for a lowerprivileged user or purpose. This can potentially expose vulnerability if the connection is not reauthorized when used by a new identity.
16 10. Data tampering. An attacker violates the integrity of data by modifying it in local memory, in a data-store, or on the network. Modification of this data could provide the attacker with access to a service through a number of the different methods listed in this document. 11. Denial of service. Denial of service (DoS) is the process of making a system or application unavailable. For example, a DoS attack might be accomplished by bombarding a server with requests to consume all available system resources, or by passing the server malformed input data that can crash an application process. 12. Dictionary attack. Use of a list of likely access methods (usernames, passwords, coding methods) to try and gain access to a system. This approach is more focused and intelligent than the brute force attack method, so as to increase the likelihood of success in a shorter amount of time. 13. Disclosure of sensitive/confidential data. Sensitive data is exposed in some unintended way to users who do not have the proper privileges to see it. This can often be done through parameterized error messages, where an attacker will force an error and the program will pass sensitive information up through the layers of the program without filtering it. This can be personally identifiable information (i.e., personal data) or system data. 14. Elevation of privilege. A user with limited privileges assumes the identity of a privileged user to gain privileged access to an application. For example, an attacker with limited privileges might elevate his or her privilege level to compromise and take control of a highly privileged and trusted process or account. More information about this attack in the context of Windows Azure can be found in the Security Best Practices for Developing Windows Azure Applications at Encryption. The process of taking sensitive data and changing it in such a way that it is unrecognizable to anyone but those who know how to decode it. Different encryption methods have different strengths based on how easy it is for an attacker to obtain the original information through whatever methods are available. 16. Information disclosure. Unwanted exposure of private data. For example, a user views the contents of a table or file that he or she is not authorized to open, or monitors data passed in plaintext over a network. Some examples of information disclosure vulnerabilities include the use of hidden form fields, comments embedded in Web pages that contain database connection strings and connection details, and weak exception handling that can lead to internal system-level details being revealed to the client. Any of this information can be very useful to the attacker. 17. Luring attacks. An attacker lures a higher-privileged user into taking an action on his or her behalf. This is not an authorization failure but rather a failure of the system to properly inform the user. 18. Man-in-the-middle attacks. A person intercepts both the client and server communications and then acts as an intermediary between the two without each ever knowing. This gives the middle man the ability to read and potentially modify messages from either party in order to implement another type of attack listed here.
17 19. Network eavesdropping. Listening to network packets and reassembling the messages being sent back and forth between one or more parties on the network. While not an attack itself, network eavesdropping can easily intercept information for use in specific attacks listed in this document. 20. Open Redirects. Attacker provides a URL to a malicious site when allowed to input a URL used in a redirect. This allows the attacker to direct users to sites that perform phishing attacks or other malicious actions. 21. Password cracking. If the attacker cannot establish an anonymous connection with the server, he or she will try to establish an authenticated connection. For this, the attacker must know a valid username and password combination. If you use default account names, you are giving the attacker a head start. Then the attacker only has to crack the account s password. The use of blank or weak passwords makes the attacker s job even easier. 22. Repudiation. The ability of users (legitimate or otherwise) to deny that they performed specific actions or transactions. Without adequate auditing, repudiation attacks are difficult to prove. 23. Session hijacking. Also known as man-in-the-middle attacks, session hijacking deceives a server or a client into accepting the upstream host as the actual legitimate host. Instead, the upstream host is an attacker s host that is manipulating the network so the attacker s host appears to be the desired destination. 24. Session replay. An attacker steals messages off of the network and replays them in order to steal a user s session. 25. Session fixation. An attacker sets (fixates) another person s session identifier artificially. The attacker must know that a particular Web service accepts any session ID that is set externally; for example, the attacker sets up a URL such as The attacker then sends this URL to a valid user, who clicks on it. At this point, a valid session with the ID is created on the server. Because the attacker determines this ID, he or she can now hijack the session, which has been authenticated using the valid user s credentials. 26. Spoofing. An attempt to gain access to a system by using a false identity. This can be accomplished by using stolen user credentials or a false IP address. After the attacker successfully gains access as a legitimate user or host, elevation of privileges or abuse using authorization can begin. 27. SQL injection. Failure to validate input in cases where the input is used to construct a SQL statement or will modify the construction of a SQL statement in some way. If the attacker can influence the creation of a SQL statement, he or she can gain access to the database with privileges otherwise unavailable and use this in order to steal or modify information or destroy data. 28. Throttling. The process of limiting resource usage to keep a particular process from bogging down and/or crashing a system. Relevant as a countermeasure in DoS attacks, where an attacker attempts to crash the system by overloading it with input.
18 Countermeasures Explained 1. Assume all input is malicious. Assuming all input is malicious means designing your application to validate all input. User input should never be accepted without being filtered and/or sanitized. 2. Audit and log activity through all of the application tiers. Log business critical and security sensitive events. This will help you track security issues down and make sense of security problems. Skilled attackers attempt to cover their tracks, so you ll want to protect your logs. 3. Avoid storing secrets. Design around storing secrets. If necessary, sometimes they can be avoided by storing them after using a one-way hash algorithm. 4. Avoid storing sensitive data in the Web space. Anything exposed to the public Internet is considered web space. Sensitive data stored in a location that might be compromised by any member of the public places it at much higher risk. 5. Back up and regularly analyze log files. Some attacks can occur over time. Regular analysis of logs will allow you to recognize with sufficient time to address them. Performing regular backups lowers the risk of an attacker covering his tracks by deleting logging of his activities. 6. Be able to disable accounts. The ability to reactively defend an attack by shutting out a user should be supported through the ability to disable an account. 7. Be careful with canonicalization issues. Predictable naming of file resources is convenient for programming, but is also very convenient for malicious parties to attack. Application logic should not be exposed to users in this manner. Instead, you use file names derived from the original names or fed through a one-way hashing algorithm. 8. Catch exceptions. Unhandled exceptions are at risk of passing too much information to the client. Handle exceptions when possible. 9. Centralize your input and data validation. Input and data validation should be performed using a common set of code such as a validation library. 10. Consider a centralized exception management framework. Exception handling frameworks are available publically and provide an established and tested means for handling exceptions. 11. Consider authorization granularity. Every object needs to have an authorization control that authorizes access based on the identity of the authenticated party requesting access. Fine grained authorization will control access to each resource, while coarse grained authorization will control access to groups of resources or functional areas of the application. 12. Consider identity flow. Auditing should be traceable back to the authenticated party. Take note of identity transitions imposed by design decisions like impersonation. 13. Constrain input. Limit user input to expected ranges and formats. 14. Constrain, reject, and sanitize your input. Constrain, reject and sanitize should be primary techniques in handling input data. 15. Cycle your keys periodically. Expiring encryption keys lowers the risk of stolen keys.
19 16. Disable anonymous access and authenticate every principle. When possible, require all interactions to occur as an authenticated party as opposed to an anonymous one. This will help facilitate more effective auditing. 17. Do not develop your own cryptography. Custom cryptography is not difficult for experts to crack. Established cryptography is preferred because it is known to be safe. 18. Do not leak information to the client. Exception data can potentially contain sensitive data or information exposing program logic. Provide clients only with the error data they need for the UI. 19. Do not log private data such as passwords. Log files are an attack vector for malicious parties. Limit the risk of their being compromised by not logging sensitive data in the log. 20. Do not pass sensitive data using the HTTP-GET protocol. Data passed using HTTP GET is appended to the querystring. When users share links by copying and pasting them from the browser address bar, sensitive data may also be inadvertently passed. Pass sensitive data in the body of a POST to avoid this. 21. Do not rely on client-side validation. Any code delivered to a client is at risk of being compromised. Because of this, it should always be assumed that input validation on the client might have been bypassed. 22. Do not send passwords over the wire in plaintext. Authentication information communicated over the wire should always be encrypted. This may mean encrypting the values, or encrypting the entire channel with SSL. 23. Do not store credentials in plaintext. Credentials are sometimes stored in application configuration files, repositories, or sent over . Always encrypt credentials before storing them. 24. Do not store database connections, passwords, or keys in plaintext. Configuration secrets should always be stored in encrypted form, external to the code. 25. Do not store passwords in user stores. In the event that the user store is compromised, an attack should never be able to access passwords. A derivative of a password should be stored instead. A common approach to this is to encrypt a version of the password using a one-way hash with a SALT. Upon authentication, the encrypted password can be regenerated with the SALT and the result can be compared to the original encrypted password. 26. Do not store secrets in code. Secrets such as configuration settings are convenient to store in code, but are more likely to be stolen. Instead, store them in a secure location such as a secret store. 27. Do not store sensitive data in persistent cookies. Persistent cookies are stored client-side and provide attackers with ample opportunity to steal sensitive data, be it through encryption cracking or any other means. 28. Do not trust fields that the client can manipulate (query strings, form fields, cookies, or HTTP headers). All information sent from a client should always be assumed to be malicious. All information from a client should always be validated and sanitized before it is used. 29. Do not trust HTTP header information. Http header manipulation is a threat that can be mitigated by building application logic that assumes HTTP headers are compromised and validates the HTTP headers before using them.
20 30. Encrypt communication channels to protect authentication tokens. Authentication tokens are often the target of eavesdropping, theft or replay type attacks. To reduce the risk in these types of attacks, it is useful to encrypt the channel the tokens are communicated over. Typically this means protecting a login page with SSL encryption. 31. Encrypt sensitive cookie state. Sensitive data contained within cookies should always be encrypted. 32. Encrypt the contents of the authentication cookies. In the case where cookies are compromised, they should not contain clear-text session data. Encrypt sensitive data within the session cookie. 33. Encrypt the data or secure the communication channel. Sensitive data should only be passed in encrypted form. This can be accomplished by encrypting the individual items that are sent over the wire, or encrypting the entire channel as with SSL. 34. Enforce separation of privileges. Avoid building generic roles with privileges to perform a wide range of actions. Roles should be designed for specific tasks and provided the minimum privileges required for those tasks. 35. Enforce unique transactions. Identify each transaction from a client uniquely to help prevent replay and forgery attacks. 36. Identify malicious behavior. Monitoring site interactions that fall outside of normal usage patterns, you can quickly identify malicious behavior. This is closely related to Know what good traffic looks like. 37. Keep unencrypted data close to the algorithm. Use decrypted data as soon as it is decrypted, and then dispose of it promptly. Unencrypted data should not be held in memory in code. 38. Know what good traffic looks like. Active auditing and logging of a site will allow you know recognize what regular traffic and usage patterns are. This is a required step in order to be able to identify malicious behavior. 39. Limit session lifetime. Longer session lifetimes provide greater opportunity for Cross-Site Scripting or Cross-Site Request Forgery attacks to add activity onto an old session. 40. Log detailed error messages. Highly detailed error message logging can provide clues to attempted attacks. 41. Log key events. Profile your application and note key or sensitive operations and/or events, and log these events during application operation. 42. Maintain separate administration privileges. Consider granularity of authorization in the administrative interfaces as well. Avoid combining administrator roles with distinctly different roles such as development, test or deployment. 43. Make sure that users do not bypass your checks. Bypassing checks can be accomplished by canonicalization attacks, or bypassing client-side validation. Application design should avoid exposing application logic, and segregating application logic into flow that can be interrupted. For example, an ASPX page that performs only validations and then redirects. Instead, validation routines should be tightly bound to the data they are validating. 44. Pass Forms authentication cookies only over HTTPS connections. Cookies are at risk of theft and replay type attacks. Encrypting them with SSL helps reduce the risk of these types of attacks.
Where every interaction matters.
Where every interaction matters. Peer 1 Vigilant Web Application Firewall Powered by Alert Logic The Open Web Application Security Project (OWASP) Top Ten Web Security Risks and Countermeasures White Paper
More informationCriteria for web application security check. Version 2015.1
Criteria for web application security check Version 2015.1 i Content Introduction... iii ISC- P- 001 ISC- P- 001.1 ISC- P- 001.2 ISC- P- 001.3 ISC- P- 001.4 ISC- P- 001.5 ISC- P- 001.6 ISC- P- 001.7 ISC-
More informationWhat is Web Security? Motivation
brucker@inf.ethz.ch http://www.brucker.ch/ Information Security ETH Zürich Zürich, Switzerland Information Security Fundamentals March 23, 2004 The End Users View The Server Providers View What is Web
More informationFINAL DoIT 11.03.2015 - v.4 PAYMENT CARD INDUSTRY DATA SECURITY STANDARDS APPLICATION DEVELOPMENT AND MAINTENANCE PROCEDURES
Purpose: The Department of Information Technology (DoIT) is committed to developing secure applications. DoIT s System Development Methodology (SDM) and Application Development requirements ensure that
More informationThick Client Application Security
Thick Client Application Security Arindam Mandal (arindam.mandal@paladion.net) (http://www.paladion.net) January 2005 This paper discusses the critical vulnerabilities and corresponding risks in a two
More informationExternal Vulnerability Assessment. -Technical Summary- ABC ORGANIZATION
External Vulnerability Assessment -Technical Summary- Prepared for: ABC ORGANIZATI On March 9, 2008 Prepared by: AOS Security Solutions 1 of 13 Table of Contents Executive Summary... 3 Discovered Security
More informationSitefinity Security and Best Practices
Sitefinity Security and Best Practices Table of Contents Overview The Ten Most Critical Web Application Security Risks Injection Cross-Site-Scripting (XSS) Broken Authentication and Session Management
More informationWeb Application Security Considerations
Web Application Security Considerations Eric Peele, Kevin Gainey International Field Directors & Technology Conference 2006 May 21 24, 2006 RTI International is a trade name of Research Triangle Institute
More informationWeb Application Security
Chapter 1 Web Application Security In this chapter: OWASP Top 10..........................................................2 General Principles to Live By.............................................. 4
More informationelearning for Secure Application Development
elearning for Secure Application Development Curriculum Application Security Awareness Series 1-2 Secure Software Development Series 2-8 Secure Architectures and Threat Modeling Series 9 Application Security
More informationFINAL DoIT 04.01.2013- v.8 APPLICATION SECURITY PROCEDURE
Purpose: This procedure identifies what is required to ensure the development of a secure application. Procedure: The five basic areas covered by this document include: Standards for Privacy and Security
More informationCheck list for web developers
Check list for web developers Requirement Yes No Remarks 1. Input Validation 1.1) Have you done input validation for all the user inputs using white listing and/or sanitization? 1.2) Does the input validation
More informationCertified Secure Web Application Secure Development Checklist
www.certifiedsecure.com info@certifiedsecure.com Tel.: +31 (0)70 310 13 40 Loire 128-A 2491 AJ The Hague The Netherlands About Certified Secure Checklist Certified Secure exists to encourage and fulfill
More informationWHITE PAPER. FortiWeb and the OWASP Top 10 Mitigating the most dangerous application security threats
WHITE PAPER FortiWeb and the OWASP Top 10 PAGE 2 Introduction The Open Web Application Security project (OWASP) Top Ten provides a powerful awareness document for web application security. The OWASP Top
More informationOWASP AND APPLICATION SECURITY
SECURING THE 3DEXPERIENCE PLATFORM OWASP AND APPLICATION SECURITY Milan Bruchter/Shutterstock.com WHITE PAPER EXECUTIVE SUMMARY As part of Dassault Systèmes efforts to counter threats of hacking, particularly
More informationApplication Security Testing. Generic Test Strategy
Application Security Testing Generic Test Strategy Page 2 of 8 Contents 1 Introduction 3 1.1 Purpose: 3 1.2 Application Security Testing: 3 2 Audience 3 3 Test Strategy guidelines 3 3.1 Authentication
More informationASP.NET MVC Secure Coding 4-Day hands on Course. Course Syllabus
ASP.NET MVC Secure Coding 4-Day hands on Course Course Syllabus Course description ASP.NET MVC Secure Coding 4-Day hands on Course Secure programming is the best defense against hackers. This multilayered
More informationArcGIS Server Security Threats & Best Practices 2014. David Cordes Michael Young
ArcGIS Server Security Threats & Best Practices 2014 David Cordes Michael Young Agenda Introduction Threats Best practice - ArcGIS Server settings - Infrastructure settings - Processes Summary Introduction
More informationLast update: February 23, 2004
Last update: February 23, 2004 Web Security Glossary The Web Security Glossary is an alphabetical index of terms and terminology relating to web application security. The purpose of the Glossary is to
More informationWeb Application Hacking (Penetration Testing) 5-day Hands-On Course
Web Application Hacking (Penetration Testing) 5-day Hands-On Course Web Application Hacking (Penetration Testing) 5-day Hands-On Course Course Description Our web sites are under attack on a daily basis
More informationKenna Platform Security. A technical overview of the comprehensive security measures Kenna uses to protect your data
Kenna Platform Security A technical overview of the comprehensive security measures Kenna uses to protect your data V2.0, JULY 2015 Multiple Layers of Protection Overview Password Salted-Hash Thank you
More informationPCI-DSS and Application Security Achieving PCI DSS Compliance with Seeker
PCI-DSS and Application Security Achieving PCI DSS Compliance with Seeker www.quotium.com 1/14 Summary Abstract 3 PCI DSS Statistics 4 PCI DSS Application Security 5 How Seeker Helps You Achieve PCI DSS
More informationIs Drupal secure? A high-level perspective on web vulnerabilities, Drupal s solutions, and how to maintain site security
Is Drupal secure? A high-level perspective on web vulnerabilities, Drupal s solutions, and how to maintain site security Presented 2009-05-29 by David Strauss Thinking Securely Security is a process, not
More informationCrashPlan Security SECURITY CONTEXT TECHNOLOGY
TECHNICAL SPECIFICATIONS CrashPlan Security CrashPlan is a continuous, multi-destination solution engineered to back up mission-critical data whenever and wherever it is created. Because mobile laptops
More informationSecure Web Application Coding Team Introductory Meeting December 1, 2005 1:00 2:00PM Bits & Pieces Room, Sansom West Room 306 Agenda
Secure Web Application Coding Team Introductory Meeting December 1, 2005 1:00 2:00PM Bits & Pieces Room, Sansom West Room 306 Agenda 1. Introductions for new members (5 minutes) 2. Name of group 3. Current
More informationOWASP and OWASP Top 10 (2007 Update) OWASP. The OWASP Foundation. Dave Wichers. The OWASP Foundation. OWASP Conferences Chair dave.wichers@owasp.
and Top 10 (2007 Update) Dave Wichers The Foundation Conferences Chair dave.wichers@owasp.org COO, Aspect Security dave.wichers@aspectsecurity.com Copyright 2007 - The Foundation This work is available
More informationCS5008: Internet Computing
CS5008: Internet Computing Lecture 22: Internet Security A. O Riordan, 2009, latest revision 2015 Internet Security When a computer connects to the Internet and begins communicating with others, it is
More informationPassing PCI Compliance How to Address the Application Security Mandates
Passing PCI Compliance How to Address the Application Security Mandates The Payment Card Industry Data Security Standards includes several requirements that mandate security at the application layer. These
More informationTHREAT MODELLING FOR SQL SERVERS Designing a Secure Database in a Web Application
THREAT MODELLING FOR SQL SERVERS Designing a Secure Database in a Web Application E.Bertino 1, D.Bruschi 2, S.Franzoni 2, I.Nai-Fovino 2, S.Valtolina 2 1 CERIAS, Purdue University, West Lafayette, IN,
More informationSample Report. Security Test Plan. Prepared by Security Innovation
Sample Report Security Test Plan Prepared by Security Innovation Table of Contents 1.0 Executive Summary... 3 2.0 Introduction... 3 3.0 Strategy... 4 4.0 Deliverables... 4 5.0 Test Cases... 5 Automation...
More informationWEB SECURITY CONCERNS THAT WEB VULNERABILITY SCANNING CAN IDENTIFY
WEB SECURITY CONCERNS THAT WEB VULNERABILITY SCANNING CAN IDENTIFY www.alliancetechpartners.com WEB SECURITY CONCERNS THAT WEB VULNERABILITY SCANNING CAN IDENTIFY More than 70% of all websites have vulnerabilities
More informationBlackBerry Enterprise Service 10. Secure Work Space for ios and Android Version: 10.1.1. Security Note
BlackBerry Enterprise Service 10 Secure Work Space for ios and Android Version: 10.1.1 Security Note Published: 2013-06-21 SWD-20130621110651069 Contents 1 About this guide...4 2 What is BlackBerry Enterprise
More informationQuickBooks Online: Security & Infrastructure
QuickBooks Online: Security & Infrastructure May 2014 Contents Introduction: QuickBooks Online Security and Infrastructure... 3 Security of Your Data... 3 Access Control... 3 Privacy... 4 Availability...
More informationColumbia University Web Security Standards and Practices. Objective and Scope
Columbia University Web Security Standards and Practices Objective and Scope Effective Date: January 2011 This Web Security Standards and Practices document establishes a baseline of security related requirements
More informationWeb Application Report
Web Application Report This report includes important security information about your Web Application. Security Report This report was created by IBM Rational AppScan 8.5.0.1 11/14/2012 8:52:13 AM 11/14/2012
More informationWeb Application Guidelines
Web Application Guidelines Web applications have become one of the most important topics in the security field. This is for several reasons: It can be simple for anyone to create working code without security
More informationWeb Application Attacks and Countermeasures: Case Studies from Financial Systems
Web Application Attacks and Countermeasures: Case Studies from Financial Systems Dr. Michael Liu, CISSP, Senior Application Security Consultant, HSBC Inc Overview Information Security Briefing Web Applications
More informationEnterprise Application Security Workshop Series
Enterprise Application Security Workshop Series Phone 877-697-2434 fax 877-697-2434 www.thesagegrp.com Defending JAVA Applications (3 Days) In The Sage Group s Defending JAVA Applications workshop, participants
More informationChapter 10. Cloud Security Mechanisms
Chapter 10. Cloud Security Mechanisms 10.1 Encryption 10.2 Hashing 10.3 Digital Signature 10.4 Public Key Infrastructure (PKI) 10.5 Identity and Access Management (IAM) 10.6 Single Sign-On (SSO) 10.7 Cloud-Based
More informationWindows Remote Access
Windows Remote Access A newsletter for IT Professionals Education Sector Updates Issue 1 I. Background of Remote Desktop for Windows Remote Desktop Protocol (RDP) is a proprietary protocol developed by
More informationOverview of Network Security The need for network security Desirable security properties Common vulnerabilities Security policy designs
Overview of Network Security The need for network security Desirable security properties Common vulnerabilities Security policy designs Why Network Security? Keep the bad guys out. (1) Closed networks
More informationDFW INTERNATIONAL AIRPORT STANDARD OPERATING PROCEDURE (SOP)
Title: Functional Category: Information Technology Services Issuing Department: Information Technology Services Code Number: xx.xxx.xx Effective Date: xx/xx/2014 1.0 PURPOSE 1.1 To appropriately manage
More informationFileCloud Security FAQ
is currently used by many large organizations including banks, health care organizations, educational institutions and government agencies. Thousands of organizations rely on File- Cloud for their file
More informationSY0-201. system so that an unauthorized individual can take over an authorized session, or to disrupt service to authorized users.
system so that an unauthorized individual can take over an authorized session, or to disrupt service to authorized users. From a high-level standpoint, attacks on computer systems and networks can be grouped
More information3. Broken Account and Session Management. 4. Cross-Site Scripting (XSS) Flaws. Web browsers execute code sent from websites. Account Management
What is an? s Ten Most Critical Web Application Security Vulnerabilities Anthony LAI, CISSP, CISA Chapter Leader (Hong Kong) anthonylai@owasp.org Open Web Application Security Project http://www.owasp.org
More information2. From a control perspective, the PRIMARY objective of classifying information assets is to:
MIS5206 Week 13 Your Name Date 1. When conducting a penetration test of an organization's internal network, which of the following approaches would BEST enable the conductor of the test to remain undetected
More informationAuditing a Web Application. Brad Ruppert. SANS Technology Institute GWAS Presentation 1
Auditing a Web Application Brad Ruppert SANS Technology Institute GWAS Presentation 1 Objectives Define why application vulnerabilities exist Address Auditing Approach Discuss Information Interfaces Walk
More information7 Network Security. 7.1 Introduction 7.2 Improving the Security 7.3 Internet Security Framework. 7.5 Absolute Security?
7 Network Security 7.1 Introduction 7.2 Improving the Security 7.3 Internet Security Framework 7.4 Firewalls 7.5 Absolute Security? 7.1 Introduction Security of Communications data transport e.g. risk
More informationPotential Targets - Field Devices
Potential Targets - Field Devices Motorola Field Devices: Remote Terminal Units ACE 3600 Front End Devices ACE IP Gateway ACE Field Interface Unit (ACE FIU) 2 Credential Cracking Repeated attempts to
More informationArchitectural Design Patterns. Design and Use Cases for OWASP. Wei Zhang & Marco Morana OWASP Cincinnati, U.S.A. http://www.owasp.
Architectural Design Patterns for SSO (Single Sign On) Design and Use Cases for Financial i Web Applications Wei Zhang & Marco Morana OWASP Cincinnati, U.S.A. OWASP Copyright The OWASP Foundation Permission
More informationOWASP Top Ten Tools and Tactics
OWASP Top Ten Tools and Tactics Russ McRee Copyright 2012 HolisticInfoSec.org SANSFIRE 2012 10 JULY Welcome Manager, Security Analytics for Microsoft Online Services Security & Compliance Writer (toolsmith),
More informationSecurity features of ZK Framework
1 Security features of ZK Framework This document provides a brief overview of security concerns related to JavaScript powered enterprise web application in general and how ZK built-in features secures
More informationAPIs The Next Hacker Target Or a Business and Security Opportunity?
APIs The Next Hacker Target Or a Business and Security Opportunity? SESSION ID: SEC-T07 Tim Mather VP, CISO Cadence Design Systems @mather_tim Why Should You Care About APIs? Amazon Web Services EC2 alone
More information05.0 Application Development
Number 5.0 Policy Owner Information Security and Technology Policy Application Development Effective 01/01/2014 Last Revision 12/30/2013 Department of Innovation and Technology 5. Application Development
More informationWeb Application Security Guidelines for Hosting Dynamic Websites on NIC Servers
Web Application Security Guidelines for Hosting Dynamic Websites on NIC Servers The Website can be developed under Windows or Linux Platform. Windows Development should be use: ASP, ASP.NET 1.1/ 2.0, and
More informationCertified Secure Web Application Security Test Checklist
www.certifiedsecure.com info@certifiedsecure.com Tel.: +31 (0)70 310 13 40 Loire 128-A 2491 AJ The Hague The Netherlands Certified Secure Checklist About Certified Secure exists to encourage and fulfill
More informationSecure Software Programming and Vulnerability Analysis
Secure Software Programming and Vulnerability Analysis Christopher Kruegel chris@auto.tuwien.ac.at http://www.auto.tuwien.ac.at/~chris Operations and Denial of Service Secure Software Programming 2 Overview
More informationEVALUATING COMMERCIAL WEB APPLICATION SECURITY. By Aaron Parke
EVALUATING COMMERCIAL WEB APPLICATION SECURITY By Aaron Parke Outline Project background What and why? Targeted sites Testing process Burp s findings Technical talk My findings and thoughts Questions Project
More informationWeb application security
Web application security Sebastian Lopienski CERN Computer Security Team openlab and summer lectures 2010 (non-web question) Is this OK? int set_non_root_uid(int uid) { // making sure that uid is not 0
More informationRecommended Practice Case Study: Cross-Site Scripting. February 2007
Recommended Practice Case Study: Cross-Site Scripting February 2007 iii ACKNOWLEDGEMENT This document was developed for the U.S. Department of Homeland Security to provide guidance for control system cyber
More informationThe Top Web Application Attacks: Are you vulnerable?
QM07 The Top Web Application Attacks: Are you vulnerable? John Burroughs, CISSP Sr Security Architect, Watchfire Solutions jburroughs@uk.ibm.com Agenda Current State of Web Application Security Understanding
More informationUnderstanding and evaluating risk to information assets in your software projects
Understanding and evaluating risk to information assets in your software projects ugh.. what a mouthful Dana Epp Windows Security MVP Who am I? Microsoft Windows Security MVP Information Security Professional
More informationDetecting Web Application Vulnerabilities Using Open Source Means. OWASP 3rd Free / Libre / Open Source Software (FLOSS) Conference 27/5/2008
Detecting Web Application Vulnerabilities Using Open Source Means OWASP 3rd Free / Libre / Open Source Software (FLOSS) Conference 27/5/2008 Kostas Papapanagiotou Committee Member OWASP Greek Chapter conpap@owasp.gr
More informationThreat Modeling. Categorizing the nature and severity of system vulnerabilities. John B. Dickson, CISSP
Threat Modeling Categorizing the nature and severity of system vulnerabilities John B. Dickson, CISSP What is Threat Modeling? Structured approach to identifying, quantifying, and addressing threats. Threat
More informationICTN 4040. Enterprise Database Security Issues and Solutions
Huff 1 ICTN 4040 Section 001 Enterprise Information Security Enterprise Database Security Issues and Solutions Roger Brenton Huff East Carolina University Huff 2 Abstract This paper will review some of
More informationWeb Plus Security Features and Recommendations
Web Plus Security Features and Recommendations (Based on Web Plus Version 3.x) Centers for Disease Control and Prevention National Center for Chronic Disease Prevention and Health Promotion Division of
More informationWeb Application Security Assessment and Vulnerability Mitigation Tests
White paper BMC Remedy Action Request System 7.6.04 Web Application Security Assessment and Vulnerability Mitigation Tests January 2011 www.bmc.com Contacting BMC Software You can access the BMC Software
More informationThe Trivial Cisco IP Phones Compromise
Security analysis of the implications of deploying Cisco Systems SIP-based IP Phones model 7960 Ofir Arkin Founder The Sys-Security Group ofir@sys-security.com http://www.sys-security.com September 2002
More informationSecurity vulnerabilities in the Internet and possible solutions
Security vulnerabilities in the Internet and possible solutions 1. Introduction The foundation of today's Internet is the TCP/IP protocol suite. Since the time when these specifications were finished in
More informationApplication Layer Encryption: Protecting against Application Logic and Session Theft Attacks. Whitepaper
Application Layer Encryption: Protecting against Application Logic and Session Theft Attacks Whitepaper The security industry has extensively focused on protecting against malicious injection attacks like
More informationUsing Foundstone CookieDigger to Analyze Web Session Management
Using Foundstone CookieDigger to Analyze Web Session Management Foundstone Professional Services May 2005 Web Session Management Managing web sessions has become a critical component of secure coding techniques.
More informationNuclear Regulatory Commission Computer Security Office Computer Security Standard
Nuclear Regulatory Commission Computer Security Office Computer Security Standard Office Instruction: Office Instruction Title: CSO-STD-1108 Web Application Standard Revision Number: 1.0 Effective Date:
More informationClient Server Registration Protocol
Client Server Registration Protocol The Client-Server protocol involves these following steps: 1. Login 2. Discovery phase User (Alice or Bob) has K s Server (S) has hash[pw A ].The passwords hashes are
More informationMagento Security and Vulnerabilities. Roman Stepanov
Magento Security and Vulnerabilities Roman Stepanov http://ice.eltrino.com/ Table of contents Introduction Open Web Application Security Project OWASP TOP 10 List Common issues in Magento A1 Injection
More informationThreat Modeling/ Security Testing. Tarun Banga, Adobe 1. Agenda
Threat Modeling/ Security Testing Presented by: Tarun Banga Sr. Manager Quality Engineering, Adobe Quality Leader (India) Adobe Systems India Pvt. Ltd. Agenda Security Principles Why Security Testing Security
More informationPenetration Test Report
Penetration Test Report Acme Test Company ACMEIT System 26 th November 2010 Executive Summary Info-Assure Ltd was engaged by Acme Test Company to perform an IT Health Check (ITHC) on the ACMEIT System
More informationGateway Apps - Security Summary SECURITY SUMMARY
Gateway Apps - Security Summary SECURITY SUMMARY 27/02/2015 Document Status Title Harmony Security summary Author(s) Yabing Li Version V1.0 Status draft Change Record Date Author Version Change reference
More informationCutting Edge Practices for Secure Software Engineering
Cutting Edge Practices for Secure Software Engineering Kanchan Hans Amity Institute of Information Technology Amity University, Noida, 201301, India khans@amity.edu Abstract Security has become a high
More informationCMP3002 Advanced Web Technology
CMP3002 Advanced Web Technology Assignment 1: Web Security Audit A web security audit on a proposed eshop website By Adam Wright Table of Contents Table of Contents... 2 Table of Tables... 2 Introduction...
More informationRuby on Rails Secure Coding Recommendations
Introduction Altius IT s list of Ruby on Rails Secure Coding Recommendations is based upon security best practices. This list may not be complete and Altius IT recommends this list be augmented with additional
More informationETHICAL HACKING 010101010101APPLICATIO 00100101010WIRELESS110 00NETWORK1100011000 101001010101011APPLICATION0 1100011010MOBILE0001010 10101MOBILE0001
001011 1100010110 0010110001 010110001 0110001011000 011000101100 010101010101APPLICATIO 0 010WIRELESS110001 10100MOBILE00010100111010 0010NETW110001100001 10101APPLICATION00010 00100101010WIRELESS110
More informationAn Approach to Threat Modeling in Web Application Security Analysis
Volume-5, Issue EICA2012-5, February 10, 2012 An Approach to Threat Modeling in Web Application Security Analysis Sreenivasa Rao B Dept. of Computer Science & Engineering CMJ University, Shillong, India
More informationHack Proof Your Webapps
Hack Proof Your Webapps About ERM About the speaker Web Application Security Expert Enterprise Risk Management, Inc. Background Web Development and System Administration Florida International University
More informationA Server and Browser-Transparent CSRF Defense for Web 2.0 Applications. Slides by Connor Schnaith
A Server and Browser-Transparent CSRF Defense for Web 2.0 Applications Slides by Connor Schnaith Cross-Site Request Forgery One-click attack, session riding Recorded since 2001 Fourth out of top 25 most
More informationDatabase security issues PETRA BILIĆ ALEXANDER SPARBER
Database security issues PETRA BILIĆ ALEXANDER SPARBER Introduction Database security is one aspect of computer security It uses different information security controls to protect databases Information
More informationSecure Web Development Teaching Modules 1. Threat Assessment
Secure Web Development Teaching Modules 1 Threat Assessment Contents 1 Concepts... 1 1.1 Software Assurance Maturity Model... 1 1.2 Security practices for construction... 3 1.3 Web application security
More informationTaxonomic Modeling of Security Threats in Software Defined Networking
Taxonomic Modeling of Security Threats in Software Defined Networking Recent advances in software defined networking (SDN) provide an opportunity to create flexible and secure next-generation networks.
More informationSENSE Security overview 2014
SENSE Security overview 2014 Abstract... 3 Overview... 4 Installation... 6 Device Control... 7 Enrolment Process... 8 Authentication... 9 Network Protection... 12 Local Storage... 13 Conclusion... 15 2
More informationJVA-122. Secure Java Web Development
JVA-122. Secure Java Web Development Version 7.0 This comprehensive course shows experienced developers of Java EE applications how to secure those applications and to apply best practices with regard
More informationIJMIE Volume 2, Issue 9 ISSN: 2249-0558
Survey on Web Application Vulnerabilities Prevention Tools Student, Nilesh Khochare* Student,Satish Chalurkar* Professor, Dr.B.B.Meshram* Abstract There are many commercial software security assurance
More informationThreat Modeling. Frank Piessens (Frank.Piessens@cs.kuleuven.be ) KATHOLIEKE UNIVERSITEIT LEUVEN
Threat Modeling Frank Piessens (Frank.Piessens@cs.kuleuven.be ) Secappdev 2007 1 Overview Introduction Key Concepts Threats, Vulnerabilities, Countermeasures Example Microsoft s Threat Modeling Process
More informationProject 2: Web Security Pitfalls
EECS 388 September 19, 2014 Intro to Computer Security Project 2: Web Security Pitfalls Project 2: Web Security Pitfalls This project is due on Thursday, October 9 at 6 p.m. and counts for 8% of your course
More informationChapter 6: Fundamental Cloud Security
Chapter 6: Fundamental Cloud Security Nora Almezeini MIS Department, CBA, KSU From Cloud Computing by Thomas Erl, Zaigham Mahmood, and Ricardo Puttini(ISBN: 0133387526) Copyright 2013 Arcitura Education,
More informationWHITE PAPER FORTIWEB WEB APPLICATION FIREWALL. Ensuring Compliance for PCI DSS 6.5 and 6.6
WHITE PAPER FORTIWEB WEB APPLICATION FIREWALL Ensuring Compliance for PCI DSS 6.5 and 6.6 CONTENTS 04 04 06 08 11 12 13 Overview Payment Card Industry Data Security Standard PCI Compliance for Web Applications
More informationServer Security. Contents. Is Rumpus Secure? 2. Use Care When Creating User Accounts 2. Managing Passwords 3. Watch Out For Aliases 4
Contents Is Rumpus Secure? 2 Use Care When Creating User Accounts 2 Managing Passwords 3 Watch Out For Aliases 4 Deploy A Firewall 5 Minimize Running Applications And Processes 5 Manage Physical Access
More informationThe Weakest Link: Mitigating Web Application Vulnerabilities. webscurity White Paper. webscurity Inc. Minneapolis, Minnesota USA
The Weakest Link: Mitigating Web Application Vulnerabilities webscurity White Paper webscurity Inc. Minneapolis, Minnesota USA January 25, 2007 Contents Executive Summary...3 Introduction...4 Target Audience...4
More informationBarracuda Web Site Firewall Ensures PCI DSS Compliance
Barracuda Web Site Firewall Ensures PCI DSS Compliance E-commerce sales are estimated to reach $259.1 billion in 2007, up from the $219.9 billion earned in 2006, according to The State of Retailing Online
More informationHow to break in. Tecniche avanzate di pen testing in ambito Web Application, Internal Network and Social Engineering
How to break in Tecniche avanzate di pen testing in ambito Web Application, Internal Network and Social Engineering Time Agenda Agenda Item 9:30 10:00 Introduction 10:00 10:45 Web Application Penetration
More informationWeb App Security Audit Services
locuz.com Professional Services Web App Security Audit Services The unsecured world today Today, over 80% of attacks against a company s network come at the Application Layer not the Network or System
More informationSession Hijacking Exploiting TCP, UDP and HTTP Sessions
Session Hijacking Exploiting TCP, UDP and HTTP Sessions Shray Kapoor shray.kapoor@gmail.com Preface With the emerging fields in e-commerce, financial and identity information are at a higher risk of being
More information