I’ve spent the past 3.5 years working on a team where my primary responsibilities involved “application security”. Now that this era has come to an end, I’d like to share some of the initiatives and define their successes and shortcomings. This is part 3 of 5 so please be sure to read parts 1 and 2.
Threat modeling, architecture reviews, and security consulting
Our application security program always offered a design review service. Initially this service wasn’t very well defined and simply involved a security engineer performing a review of available documentation and interviews with the development team. The outcome of this engagement was a series of recommendation and requirements for the project to implement during the development phase. As you can imagine, this approach was very subjective and lacked documentation, but formalization of the offering was put on the back burner due to the successes with the penetration testing offering.
A little over a year and a half after the application security program was defined, we started focusing on assimilating some of the industry proven approaches to threat modeling and security architecture best practices into our existing design review service. We leveraged the opportunities presented by the local OWASP chapter and were able to obtain the training in formal threat modeling approaches that we were easily able to adapt and offer as a fully documented and repeatable process. Unfortunately, my time with the team was up before we could really determine the effectiveness of this service offering. My hope was that we could use this service to not only identify deficiencies in secure design early in the lifecycle, but also to setup a plan for providing training, code review / SCA services, and penetration testing at the appropriate times. This would effectively setup a consulting relationship between the individual security engineers and the project team where a single person / team could be leveraged for all aspects of application security.
In this time of shrinking budgets, reduced staff, and other various financial constraints, security departments world wide are looking for ways to justify the expense of a well rounded application security program. Jeremiah Grossman (WhiteHat Security / OWASP) and Jeff Williams (Aspect Security / OWASP) have collaborated on a fantastic article that is sure to get security engineers, developers, and managers alike lining up at their executives’ door armed with some great arguments in support of creating or expanding their application security programs.
While I fully support and endorse the content of the article, I can already see the responses from some executives:
“Wow, this is really great, and I fully buy into it, but as it stands, there is REALLY no money extra money in the budget.”
What now? Hopefully, there are employees in your company who are responsible for managing servers, the domain, the networks/firewalls/IDS/IPS, and development efforts; but most importantly, you, who is concerned about the state of application security. Why not use some of the best resources from those groups to form an application security working group? I’ve found that no matter what the company, there are ALWAYS people that are interested in being able to devote some time to learning about how those sneaky hackers are able to break into so many systems. Furthermore, what (good) technologist wouldn’t be interested in expanding their skills?
I’m sure that you’ll encounter some resistance from employees and management alike, after all, time is valuable, but remember, Jeremiah and Jeff have already given you all the ammo you need; use it wisely.
Now that you’ve identified folks who are willing to donate some of their valuable time to this effort, your first step will be educating them about the various activities and processes involved with a complete application security program. Here’s a quick reminder:
Design and architecture reviews and threat models where you work to identify flaws in the application design and architecture as well as imposing security requirements.
Secure coding standards where you work to ensure that developers implement features such as input validation, authentication, authorization, and avoid creating flaws in the business logic as they move through implementation.
Code reviews where through either automated or manual means, developers review their code with a focus on identifying any security issues.
Testing and validation where you ensure that all requirements have been implemented according to design specs.
Deployment and maintenance where you ensure that logs are being monitored, system patches are being kept up to date, and 3rd party libraries used in the application are kept up to date.
The chances are good that some of the folks that have chosen to join the security working group already have some valuable input to provide. For example, the sysadmins might have expertise in Apache, host configuration management, or IPTables. The network folks might have been exposed to web application firewall technology. The developers might have some great security specific libraries that they’ve used on past projects. All of this knowledge is valuable and already at your finger tips. For other topics, search around your social network, if you’re on Twitter, checkout @securitytwits, if you’re a member of OWASP, attend the meetings, talk to folks, try to get an idea of their expertise. Many of the seasoned security professionals who attend these meeting would be happy to come in and present at one of your groups meeting.
So, get out there, talk to people both within and outside of your company, not only will you expand your social network and improve your companies application security program, but you’ll also be giving new opportunities to those who join the security working group.
The majority of companies out there have implemented some sort of Windows Active Directory system that they use to connect and manage desktop systems, servers, printers, and other networked assets in a “secure” way. I use secure in quotes because the security largely depends on individual implementations. In any event, the Open Source community builds some pretty cool web apps on top of Apache that would be very useful for collaborating, code management, etc. One of the pain points for companies choosing Open Source web solutions has been the custom authentication and authorization implemented in the applications.
mod_auth_kerb extends Apache’s Basic Auth functionality to authenticate enterprise users against Windows Active Directory using Kerberos tickets supported by Windows. mod_authnz_ldap can use the Active Directory LDAP server to evaluate any available LDAP field against administrator defined ACL. For example, Company X decides to use an Open Source web application but want to restrict access to those in the Active Directory Administrators group; mod_authnz_ldap can use the LDAP server to pull the Active Directory group for the user it’s authenticating and determine whether they are part of the Administrators group.
Here’s a quick summary of how to get it working:
Ensure that your Apache is build with –enable-ldap –enable-authnz-ldap –with-ldap.
Configure Apache to use mod_authnz_ldap to authorize access based on LDAP data: Global Apache configurations:
LDAPTrustedMode SSL (optional) LDAPTrustedGlobalCert CA_DER /etc/apache2/ssl/AOL_Member_CA.der # If the SSL certificate on ldaps is not recognized
LDAPVerifyServerCert off
Directory Apache configurations:
RequireSSL # because you don’t want Active Directory credentials in the clear
AuthLDAPURL ldaps://directoryserver:port/dc=somewhere,dc=com?cn SSL # where CN is the unique username
AuthLDAPRemoteUserIsDN off
AuthLDAPBindDN DNUsername
AuthLDAPBindPassword DNPassword
require ldap-attribute ldapfieldname = “ldapfieldvalue”
require ldap-attribute ldapfieldname = “ldapfieldvalue”
Set Apache’s LogLevel to debug and start troubleshooting. Having an LDAP browser available to test will help you determine where the issues are when troubleshooting.
I ran into a small problem while getting this setup. I found that mod_auth_kerb was modifying the Apache Basic Auth “user” field from the username provided at login to username@realm. This might not be a problem in most cases, but for my implementation, username@realm was no where to be found in the Active Directory LDAP data. So, I did the following quick hacks to the mod_auth_kerb source code and recompiled:
Comment out user = apr_pstrcat(r->pool, user, “@”, realm, NULL);
This small change makes mod_auth_kerb return the username instead of username@realm. I’ve emailed the maintainers of mod_auth_kerb to see if they would consider adding an configuration flag to enable the stripping of @realm.
mod_auth_kerb supports SPNEGO (Windows Integrated Authentication support in IE and Firefox) which can provide Single Sign On for Windows users authenticated to the Active Directory.
Firefox: In about:config, change the value in network.negotiate-auth.trusted-uris to https://the.url.for.your.app
Since mod_auth_kerb and mod_authnz_ldap simply hook the Apache Basic Auth functionality, applications can leverage the Apache server to provide a username to the underlying web application.
Here are a couple apps you might want to test your new authentication with:
As a web application security testing professional, you often encounter “snake oil” security implementations. A recent example would be the “Hacker Safe” ruse which has been exposedtime and time again by the security community. Today, I come to you with another: Partially encrypted web applications aren’t protecting you!! Let me explain the situation. Most web applications have implemented SSL/TLS encryption for you to login without exposing your username and password to the guy in the black trench coat also using the wifi at the coffee shop. This kind of protective measure inspires the trust of the user in the application, but does very little to actually protect your identity, data, or in the event of social applications, your reputation.
At the heart of the problem is the way that the web server maintains a unique session for each visitor: by setting and tracking a unique value in the cookie. Once a visitor logs in, the unique web server session is bound to the authenticated user making the session identifier equivalent to the username and password. To further compound the issue, the contents of the cookie are automatically transmitted over the network with each request that the browser issues to the webserver.
Once an attacker has sniffed the contents of the web application’s cookie from the network, they have obtained the key component for impersonating the victim on the target site:
Social Networks – an attacker can perform smear campaigns by posting items to the targeted profile for the victim’s contacts to see.
WebMail – an attacker can create a mail filter to read the victim’s email. This attack has already resulted in a blogger being victim to domain hijacking.
Administration Interfaces – an attacker can perform unauthorized changes to devices or services which utilize administrative interfaces to update settings.
Financial Applications – an attacker could steal money or financial information on vulnerable web applications. (Applications which accept credit card payments are subject to PCI-DSS compliance and lack of encryption would no comply. Sites who only accept PayPal or other online payment processors are not subject to PCI-DSS).
Application users must learn to recognize when they’re being misinformed about risk and demand more security from the vendors. Application designers and vendors must implement encryption for the entire application. If the additional server resources are of concern, a hardware appliances for SSL/TLS can be installed so that the web server does not suffer from the overhead resource consumption.
I’ve spent the past 3.5 years working on a team where my primary responsibilities involved “application security”. Now that this era has come to an end, I’d like to share some of the initiatives and define their successes and shortcomings. This is part 3 of 5 so please be sure to read parts 1 and 2.
In this time of shrinking budgets, reduced staff, and other various financial constraints, security departments world wide are looking for ways to justify the expense of a well rounded application security program. 
The majority of companies out there have implemented some sort of Windows Active Directory system that they use to connect and manage desktop systems, servers, printers, and other networked assets in a “secure” way. I use secure in quotes because the security largely depends on individual implementations. In any event, the Open Source community builds some pretty cool web apps on top of Apache that would be very useful for collaborating, code management, etc. One of the pain points for companies choosing Open Source web solutions has been the custom authentication and authorization implemented in the applications.
As a web application security testing professional, you often encounter “snake oil” security implementations. A recent example would be the “
DandyID
Friendfeed
claimID
Disqus
Facebook
Twitter
myOpenID
Google Profiles
Linkedin