CFUNITED - Top 10 Security Threats
Adam Lehman works for the State Department, and knows very well the intricacies of hardening a ColdFusion application. In this enlightening and informative session. he walked us all through the top 10 most common security holes found in applications in general, and then expounded upon ways to address these holes for CF applications. Let's count them down together.
Number 10. Insecure Configuration Management. An app can be anally secure, but if you don't remember to actually secure the interface used to manage that security, it's all for nought. Some things to remember for this one are:
Number 9. Denial of Service Attacks. Bots and scripts designed to do nothing more than pound your application with a barrage of legitimate http requests, doing so at such a rate as to consume all available resources on the server. For this one, there really isn't a lot that can be done from an application architecture point of view. It can help if you limit your need to access databases and how much data is stored in session. Ultimately, however, your best bet lies in ensuring that all server patches and service paks are kept up to date, as well as networking hardware designed to sense and deal with DNS(denial of service) attacks.
Number 8. Insecure Storage. The need to access application-centric, sensitive data exists. Information such as datasource names, usernames, passwords, social security or credit card numbers are all types of information that need to be protected. The main tip provided to help address this area of compromise was to either encrypt or hash the information before storing it, if possible. If not, then tuck it away into a most obscure location, preferably not in the path of the webroot.
Number 7. Improper Error Handling. Error handling is in place to help the developer by showing him or her as much information as possible about the unplanned situation that just took place. When an application doesn't intercept and intelligently redirect errors, information that provides clues as to the database structure, application structure, and server can be revealed to would-be hackers. The answer is to implement an application-wide error handling mechanism that diverts detailed info to email or a log while showing the end user something more generic. This error handling code should preferably in a central location such as application.cfm/cfc. In addition, you can and perhaps should disable robust error handling and debugging in the CF Administrator.
Number 6. Injection Flaws. Here's one we don't often (if ever) hear about typically. This requires a bit more sophistication on the part of the hacker. What happens is that the hacker hijacks a variable, or finds some other way, to inject malicious script code into your application. Most times this code's target isn't your application at all, but some other underlying system such as the database or the server itself. Some things that can be done to make it more challenging for the hacker:
Number 5. Buffer Overflow. Not typically a concern of web apps. For this one, like 9, make sure to keep patches up to date.
Number 4. Cross Site Scripting Flaws (aka, XSS). unlike injection flaws (number 6), XSS injects code that targets other users of the system. This is done in two manners: stored, and reflected. Stored XSS will do things such as write javascript functions to the template, where it will execute whenever that template is requested, performing some action on the client side. Reflected XSS utilizes such things as email to reflect the attack to users on other systems. Here are some things you may want to consider:
Number 3. Broken Authentication and Session Management. Well, not really broken, just weak. Here are some tips for strengthening these items:
Enforce more complex password rules, such as requiring special characters, etc.
Limit failed login attempts. When a user exceeds the count, lock them out for a period of time.
Number 2. Broken Access Control. Basically, the code you use to "lock down" certain areas of your application that require a person be authenticated for access. The recommendation here is that, rather than scatter "login checking" throughout the app, move it to a central place that runs on every request, such as application.cfc.
And Number 1: Unvalidated Input. DO validate submitted data! You can never have too much validation in place. You may use client side javascript to perform validation, but never rely on it as your primary validation. Consider the following:
Number 10. Insecure Configuration Management. An app can be anally secure, but if you don't remember to actually secure the interface used to manage that security, it's all for nought. Some things to remember for this one are:
- Do not deploy CF Admin or sample applications to your production environment.
- Do not deploy RDS to a production environment. RDS is strictly for development, and should have no place in production whatsoever.
Number 9. Denial of Service Attacks. Bots and scripts designed to do nothing more than pound your application with a barrage of legitimate http requests, doing so at such a rate as to consume all available resources on the server. For this one, there really isn't a lot that can be done from an application architecture point of view. It can help if you limit your need to access databases and how much data is stored in session. Ultimately, however, your best bet lies in ensuring that all server patches and service paks are kept up to date, as well as networking hardware designed to sense and deal with DNS(denial of service) attacks.
Number 8. Insecure Storage. The need to access application-centric, sensitive data exists. Information such as datasource names, usernames, passwords, social security or credit card numbers are all types of information that need to be protected. The main tip provided to help address this area of compromise was to either encrypt or hash the information before storing it, if possible. If not, then tuck it away into a most obscure location, preferably not in the path of the webroot.
Number 7. Improper Error Handling. Error handling is in place to help the developer by showing him or her as much information as possible about the unplanned situation that just took place. When an application doesn't intercept and intelligently redirect errors, information that provides clues as to the database structure, application structure, and server can be revealed to would-be hackers. The answer is to implement an application-wide error handling mechanism that diverts detailed info to email or a log while showing the end user something more generic. This error handling code should preferably in a central location such as application.cfm/cfc. In addition, you can and perhaps should disable robust error handling and debugging in the CF Administrator.
Number 6. Injection Flaws. Here's one we don't often (if ever) hear about typically. This requires a bit more sophistication on the part of the hacker. What happens is that the hacker hijacks a variable, or finds some other way, to inject malicious script code into your application. Most times this code's target isn't your application at all, but some other underlying system such as the database or the server itself. Some things that can be done to make it more challenging for the hacker:
- Setup sandboxes in order to limit access to such CF system tags as CF_Execute and CF_Registry.
- Limit the database access of the user that drives your CF data sources to only what is needed.
Number 5. Buffer Overflow. Not typically a concern of web apps. For this one, like 9, make sure to keep patches up to date.
Number 4. Cross Site Scripting Flaws (aka, XSS). unlike injection flaws (number 6), XSS injects code that targets other users of the system. This is done in two manners: stored, and reflected. Stored XSS will do things such as write javascript functions to the template, where it will execute whenever that template is requested, performing some action on the client side. Reflected XSS utilizes such things as email to reflect the attack to users on other systems. Here are some things you may want to consider:
- CF Admin has a "magic checkbox" to enable protection for all scopes. This will perform system regex checks against variable values flowing through CF to ensure no malicious code is present.
- Within your application.cfc, the line "this.ScriptProtected" enables protection on an application level as well.
Number 3. Broken Authentication and Session Management. Well, not really broken, just weak. Here are some tips for strengthening these items:
Enforce more complex password rules, such as requiring special characters, etc.
Limit failed login attempts. When a user exceeds the count, lock them out for a period of time.
- Store passwords as a hash rather than human text.
- Perform the actual authentication process via https/ssl
- Transmit session IDs via https/ssl
- Do not put session IDs into the url
- Use J2EE sessions
Number 2. Broken Access Control. Basically, the code you use to "lock down" certain areas of your application that require a person be authenticated for access. The recommendation here is that, rather than scatter "login checking" throughout the app, move it to a central place that runs on every request, such as application.cfc.
And Number 1: Unvalidated Input. DO validate submitted data! You can never have too much validation in place. You may use client side javascript to perform validation, but never rely on it as your primary validation. Consider the following:
- Build in server side validation to ensure that submitted data is of the expected types
- use cfqueryparam to ensure that values submitted to queries are of the correct types
- put as much of your functionality into CFCs as possible, as the inherent use of CFARGUMENT will be yet another level of validation.
- Learn about and USE the CF function IsValid(). Do it. Do it.
Subscription Options
You are not logged in, so your subscription status for this entry is unknown. You can login or register here.
No comments found.