The Ultimate Guide to Choosing WordPress Pros and Cons
EISA Considerations for Web Application Security
1.
2. Information Security for a
Web-based Business Process
A proposal for the appropriate tools for detection and
prevention of security vulnerabilities within an enterprise
information systems architecture for a given business
process.
3. Profiling
• Web Platform – the web server the application runs on
and/or the language the application was written in
• Web Authentication – password, multifactor (reCAPTCHA),
online authentication (e.g. WIndows Live ID)
• Web Authorization – attacking the web application’s
access controls through advanced session analysis,
hijacking, and fixation techniques
• Input Injection Attacks – XSS, SQL injection, buffer
overflows
• XML Web Services – WSDL disclosure, input injection, external entity
injection, and XPath injection
• Web Application Management – “attacks against remote server
management, web content management/authoring, admin
misconfigurations, and developer-driven mistakes.”
• Web Client – exploits in the web browser itself.
4. Specific Attacks
OWASP Top Ten for 2010
1. Injection
2. Cross-Site Scripting (XSS)
3. Broken Authentication and Session Management
4. Insecure Direct Object References
5. Cross-Site Request Forgery (CSRF)
6. Security Misconfiguration
7. Insecure Cryptographic Storgage
8. Failure to Restrict URL Access
9. Insufficient Transport Layer Protection
10. Unvalidated Redirects and Forwards
Being aware of the common exploits (even older ones),
as well as securing the operating system and web server
is essential.
5. Threat Modeling
Threat modeling is one of the most critical steps you can take to improve
the security of your web applications (Scambray, 2010).
Threat modeling should be used during the development and
requirements phase of design – the results will affect coding and
testing of the application.
“Threat modeling is the process of systematically deriving the key
threats relevant to an application in order to efficiently identify and
mitigate potential security weaknesses before releasing it” (Scambray,
Liu & Sima, 2011).
6. Threat Modeling
Asset identification (e.g., business logic, customer information,
financial information) that is encompassed by the application, along
with a data flow diagram to establish the flow of sensitive information
through the application and associated systems aids in threat
modeling.
A major part of threat modeling is deconstructing the application in
terms of security regions – authentication/authorization, logging,
interface, privileges, etc.
• Confidentiality, integrity, availability, and audit logging (CIAA)
should be considered for each asset documented.
• Microsoft’s STRIDE model – spoofing, tampering, repudiation,
information disclosure, denial of service, and elevation of privileges
is another helpful tool to think creatively regarding potential threats
7. Threat Modeling
Threats are then documented and ranked based on the seriousness of
the threat. Mitigations of threats would be implemented in the
development process.
Risk = Impact x Probability
Where impact is expressed in financial terms – gives a hard estimate in
dollars.
8. Code Review
Mitigation of threats in the development phase
• code review of components
• implementation of countermeasures
Manual code review is the best, but the costliest in terms of time.
Critical components that qualify for a manual code review include:
• Modules that perform data sanitization and interact with
databases
• Authentication components
• Authorization and session management
• Administration and user management
• Error and exception handling
• Cryptographic modules
• Code running with excessive privileges
• Code running that crosses multiple security contexts
• Client-side code that could be subject to debugging
9. Code Review
Common security issues
• Input handling
• SQL statement formation
• Storing secrets in code
• Authorization/Session management
• Test code remaining in production code release
10. Security Assessment Tools
Sprajax is an FLOSS black box security scanner used to assess the
security of AJAX-enabled applications – an OWASP Project
MetaSploit – Simplifies network discovery and vulnerability
verification, increasing the effectiveness of vulnerability scanners such
as Nexpose.
Nessus 5 – the most widely-deployed vulnerability and configuration
assessment product worldwide
There are also many commercial web application security scanning
programs available, such as HP WebInspect, IBM AppScan, Cenzic
Hailstorm, and NTObjectives NTOSpider.
Some organizations such as WhiteHat Security and HP SaaS Application
Security Center will scan your application and report the results to you
as well.
11. References
MetaSploit. (2012). MetaSploit penetration testing software. Retrieved
February 15, 2012 from http://www.metasploit.com/
Nessus. (2012). Nessus 5.0 is here. Retrieved
February 15, 2012 from http://www.nessus.org/products/nessus
Open Web Application Security Project. (2011). Main Page - OWASP.
Retrieved November 30, 2011 from https://www.owasp.org/
index.php/Main_Page
Scambray, J., Liu, V., & Sima, C. (2011). Hacking exposed web
applications: web application security secrets and solutions. [Kindle
Edition Version]. Chicago: McGraw Hill.
xkcd. (2011). Exploits of a mom. Retrieved February 15, 2012 from
http://xkcd.com/327/
Editor's Notes
\n
We are using the term “enterprise” here loosely, the same principles apply to small and medium sized businesses or organizations.\n
\n
My paper gave a general overview of the various attack vectors to show how prevalent web application security vulnerabilities are.\n
If security is integrated into each phase of the development process, then threat modeling is introduced in the requirements phase of the development cycle. This is logical since the results will influence coding and testing of the web application.\n
\n
Perhaps a figure that can be provided to management.\n
Some advocate having the manual code review performed by pairs of programmers/web developers \n
The test code remaining in production source is one that when I first read it, I thought, oh I’d never be that careless. But since then I’ve worked on a large, complex administrative back end for a site, and on final review before posting changes, I sometimes find test code that needs to be commented out or removed.\n
I’m not really going to go into any detail about any commercial solutions except to say that they are out there and may be an alternative tool for security analysis.\n