What is the 'Input' in Input Validation?
By Justin C Miller
Posted 9/10/2014
You are a programmer. You've heard of those nasty words like SQL Injection and Cross-Site Scripting (XSS) and Buffer Overflow. You've learned that a key step to preventing them is to perform Input Validation. You sorta know how to do that with things like ...
- Strongly Typed data
- Whitelisting
- Regular Expressions
- Max and Min length checks
You might even be a bit further ahead in the game and know about Security focused encoding libraries like WPL, Coverity Security Library, or the OWASP Reform library.
But an even more important question that I think a lot of developers overlook is the "What INPUT do I apply this validation to?"
The simple answer is ALL INPUT.
The more complicated question becomes, "What is input?"
You always validate the input of a TEXTBOX. If you are a web developer you probably also know that people like to tinker with QUERY STRING PARAMETERS so you validate them. Is that it? Are we done? Is my application safe?
Hopefully your school, or your PCI auditor, or your teammates taught you better. There's a lot more work to do.
Some of the simpler ones to remember involve websites. COOKIES for example are easy to modify (for Internet Explorer all you need is Notepad) so you better validate them. URLS themself should also be validated before used since they're freely modifiable by any user in the address bar of their browser. Why validate? Imagine if I used a cookie value to query the database for a user record. Sounds ripe for SQL Injection. Or imagine if I displayed the current Url onto the screen of an error page. Sounds like a chance for using XSS to inject an iframe.
If you've ever heard of tools like TamperData, Burp, or Fiddler you'll know that HIDDEN FIELDS on your website can also be modified so you better validate them. And those tools let you modify HTTP HEADERS like REFERRER and USER AGENT so you better validate them before they're used. Not convinced its necessary? Imagine you base a SQL query off a hidden field or recording the referrer in a table for analytics. Sounds like SQL injection is in play. Are you checking the user agent to validate what browsers you support and then displaying the user agent if you rejected them? Sounds like XSS could occur.
Other ones that might get overlooked include CHECKBOXES, RADIO BUTTONS, and DROP DOWNS. Client side it kinda seems like these are non-editable. But truth is if you have any of those free tampering tools, you can change the values. Why care? I'm guessing you are querying the database based on their values so SQL injection is in play and this you better validate them.
In a Windows Form application you might need a DATAGRID that gives the user the feel they are directly editing a SQL table. You better perform input validation here since you touching the database.
VIEW STATE on a web page can be messed with thus you better validate and treat it as input to prevent attacks.
I also would not trust SESSION STATE data. Who knows where it came from or how it got filled. If you're querying you database based on information you had saved in the session, I'd be sure to validate it and prevent SQL Injection.
Another crazy one I've seen before that is worth considering is HTML CONTROL ATTRIBUTES. For example, if you're writing any of your code's logic based on what is in the control's CLASS attribute, be careful ... you might open the door to one of these attacks and this you better validate and treat it as input.
Another one I've seen that is commonly overlooked is WEB SERVICE REQUEST PARAMETERS, XML, etc. To me a call to a web service is the equivalent of a user filling in a bunch of textboxes and hitting submit, thus you better validate it to prevent attacks. Otherwise an attacker may try to cause a buffer overflow and get their malicious code to run on your server.
I've been talking a lot about websites, but there are reasons to be concerned with internal attacks by employees or attacks that can occur once the bad guy got inside your network or even attacks coming in from 3rd parties and their system integrations. Some examples of where this comes into play include a DATA IMPORT you might do from a CSV, or from an FTP'd file, or from data brought in by a job or SSIS package. Imagine if the feed you received and saved into your database table was information you displayed on your e-Commerce product page of your website. Sounds like a ripe opportunity to perform some XSS and inject and iframe to my evil site. Better validate!
s
What if your program queries a user-accessible folder and READS IN FILES it finds? I wouldn't trust that data ... It could be used cause a buffer overflow and write over the program counter and execute malicious code.
If you are into writing scripts and command line programs don't forget to validate the COMMAND LINE PARAMETERS and FLAGS because they could be used for buffer overflows.
Have an open mind and remember that input comes in many forms, all of which should be validated. Remember all applications including Web apps, Windows apps, scripts, web services, and many more all require input validation. Remember when coding that no user can be trusted, not a guest, not an employee, not IT staff, not an administrator ... So validate all their input every time! Remember also that no data should be trusted, doesn't matter if it was inputted on a screen, read in from a CSV file, or is sent to you as XML in a nightly job ... It should all be validated.
In summary here is a good start to a list of what input requires validation and protection against things such as SQL Injection and XSS and Buffer Overflow
- Form data such as:
--- Textbox
--- Checkbox
--- Radio button
--- Drop down
--- Data Grids
- Hidden Fields
- Script Parameters
- Command Line Arguments
- Data from a file (e.g. CSV)
- Data from another source
- Data Imported (e.g. SSIS packages)
- Website specifics such as:
--- URLs
--- Query Strings
--- Cookies
--- Session State
--- View State
--- Http Headers such as:
------ User agent
------ Referrer
--- Html attributes such as:
------ Class
------ Style
- Web Service request parameters
Happy coding!
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Wednesday, September 10, 2014
Wednesday, September 3, 2014
You Can't Protect What You Don't Know
You Can't Protect What You Don't Know
By Justin C Miller
Posted 9/3/2014
Imagine you're placed into a crowd of people at a park and asked to make sure that none of the peoples' PII they have on them escapes the park. The problem is you don't know which people have PII with them and which don't. And you also don't know what types of PII they might be carrying (drivers license? Credit card? Medicare card? Social security card? A post-it note with their bank pin #?). And you don't know where they've stored their PII (in a purse? On their iPhone? Rolled up in a ball in their pocket?). And for that matter of the people in the crowd you don't even know who are the good guys and who are the bad guys.
Welcome to the world of information security! Protecting stuff you don't know or understand is messy, perhaps impossible.
In order to protect your environment you need to know it inside and out, better than any other person or department in your company. You need the big picture understanding of what you have, how important each thing you have is, and how at risk each item is.
I've built a starter list of 10 lists of things to know in order to protect adequately protect your environment. I encourage you to dig deeper and collect even more information, but this should be a good start for you ... Also it's worth noting that if you're doing ITIL and Change Management correctly then you should already have a beautiful CMDB that has a lot of this information. But if you don't, here are some places to start ...
1.) Subnets - what does your network topology look like?
2.) Servers - in each subnet what servers exist?
3.) Applications - what is each server used for, what applications are running?
4.) Network devices - what devices exist that allow your servers to talk?
5.) Workstations - what user devices exist
6.) Users - what users login to your systems?
7.) External Entities - what other applications, users, servers, etc play a role in your environment but exist outside your realm? (Examples: external hosting, cloud services, business partners)
8.) Public Knowledge - recon yourself from the outside and determine what information is already public knowledge (Examples: google search results, public records, externally exposed devices)
9.) Enemies - know who might have a non-positive attitude towards you, including competitors, political foes, past employees, etc
10.) Vulnerabilities - using all the information above such as application versions, server operating systems, and also vulnerability scans of your environment to determine a list what vulnerabilities exist in your environment
Having information like the 10 lists above will become crucial reference points as you attempt to manage your next incident or socialize your next policy or perform your next risk assessment. You can't protect what you don't know ... So get out there and start KNOWING :-)
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
By Justin C Miller
Posted 9/3/2014
Imagine you're placed into a crowd of people at a park and asked to make sure that none of the peoples' PII they have on them escapes the park. The problem is you don't know which people have PII with them and which don't. And you also don't know what types of PII they might be carrying (drivers license? Credit card? Medicare card? Social security card? A post-it note with their bank pin #?). And you don't know where they've stored their PII (in a purse? On their iPhone? Rolled up in a ball in their pocket?). And for that matter of the people in the crowd you don't even know who are the good guys and who are the bad guys.
Welcome to the world of information security! Protecting stuff you don't know or understand is messy, perhaps impossible.
In order to protect your environment you need to know it inside and out, better than any other person or department in your company. You need the big picture understanding of what you have, how important each thing you have is, and how at risk each item is.
I've built a starter list of 10 lists of things to know in order to protect adequately protect your environment. I encourage you to dig deeper and collect even more information, but this should be a good start for you ... Also it's worth noting that if you're doing ITIL and Change Management correctly then you should already have a beautiful CMDB that has a lot of this information. But if you don't, here are some places to start ...
1.) Subnets - what does your network topology look like?
2.) Servers - in each subnet what servers exist?
3.) Applications - what is each server used for, what applications are running?
4.) Network devices - what devices exist that allow your servers to talk?
5.) Workstations - what user devices exist
6.) Users - what users login to your systems?
7.) External Entities - what other applications, users, servers, etc play a role in your environment but exist outside your realm? (Examples: external hosting, cloud services, business partners)
8.) Public Knowledge - recon yourself from the outside and determine what information is already public knowledge (Examples: google search results, public records, externally exposed devices)
9.) Enemies - know who might have a non-positive attitude towards you, including competitors, political foes, past employees, etc
10.) Vulnerabilities - using all the information above such as application versions, server operating systems, and also vulnerability scans of your environment to determine a list what vulnerabilities exist in your environment
Having information like the 10 lists above will become crucial reference points as you attempt to manage your next incident or socialize your next policy or perform your next risk assessment. You can't protect what you don't know ... So get out there and start KNOWING :-)
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Monday, September 1, 2014
Security Implications of Agile vs Waterfall
Security Implications of Agile vs Waterfall
By Justin C Miller
Posted 9/1/2014
Projects are a necessity in the corporate world. They provide a means for justification and cost estimation. They give guidance and put standards around big changes. They ensure something is built to be efficient and beneficial and well tested. They provide a means to look back, reflect, and improve for the next time.
Two of the more common methodologies you'll find are Waterfall and Agile.
In waterfall you do things in sequence one after another such as requirements, design, development, testing, and release. In general you end up with large volumes of documentation and a lengthy but thorough process. There tends to also be the risk that you'll build something big only to find out when you pass it off that it's no longer what the business wanted.
In Agile you do all those things, but in small tiny waves. In general you end up with very little documentation but you see results almost immediately. You can eliminate the risk of big surprises because the business is involved during each of those tiny waves.
So, a question you might contemplate is in terms of IT Security, does it matter whether my company is using Agile or Waterfall?
I contend that YES, the choice your company makes for Project Methodology has big implications on your company's IT security. I'll skip the dance and games and get straight to the point ... Agile has become a necessity in the corporate world if you're hoping to ensure your environment is secure.
Agile builds your massively complex software in small tiny waves, perhaps 2-4 weeks at a time.
Here are 5 examples of why Agile promotes a more secure environment than Waterfall ever will ...
1.) In Agile there are fewer features built at a time thus it easier to test, and testing is an important step in finding security vulnerabilities. Imagine being asked to test whether the security groups are configured correctly in your application's 10 administrative screens, each of which have 50 tests cases each. Would you be more likely to get it right if you had to test one of the screens/50 test cases at a time, or if you had to test all 10 screens and 500 test cases at once ? Short and sweet means you can concentrate more and feel less stressed and time constrained and get it right.
2.) There are fewer lines of code to review at a time, thus the peer reviews of the code are going to be done more thoroughly and get a good solid look. I've seen it happen way too many times where in your waterfall project you just get done creating 100's of code files and 1000s of lines of code, and now your code review becomes weak and pathetic ... because you'll NEVER get a developer to review 100's of files and 1000s of lines of code in one shot. But in an Agile scenario it is much more realistic to expect them to view a handful of files and a few lines of code and review it correctly.
3.) One of the key aspects of IT security is code complexity. The simpler the code, the easier it is to secure, the easier it is to understand and the less likely it is to contain a mistake. Thus Agile brings big benefits again because you're writing smaller chunks of code that are less complex and thus by default easier to secure.
4.) Waterfall projects have a history of lasting months if not years from inception till completion. If you've been paying attention to the current state of IT security then you know that things change much quicker than that in our arena. Therefore if you start a project on a certain version of software using certain defense techniques, by the time the project is complete the vendor has probably released numerous software updates, security patches, and even the techniques used to prevent and mitigate vulnerabilities may have changed. Thus by the time a Waterfall project is deployed it's likely already old and out of date and needing an upgrade. Agile on the other hand is pushing out fixes every few weeks and by definition allowing for changing requirements, not just changing business requirements but also changing security requirements. If a patch or vulnerability needs a quick fix, you're able to toss it into the backlog as a feature on the next wave. With Waterfall you'll have a nightmare of a time trying to work it in, and things that get pushed to the backlog in Waterfall typically wait until the project is completely over. Too long in our world.
5.) The biggest, and perhaps least obvious advantage that Agile brings to the table over waterfall is a mindset. You go from moving slow, turning the Titanic, to moving swiftly, piece-mealing it to get the job done quickly. I've seen it many times already where those companies stuck in the mindset of Waterfall are the same companies that struggle to get security patching done because they want to plan it for a month, test it for another month or two, then deploy after a few weeks of Change Advisory board discussions. This of course leaves your company open and vulnerable while you're waiting for the process to play out. The Waterfall mindset also leads to end-of-life software hanging out there because the project is just too large and intense to upgrade ... which obviously is a huge security risk. The Waterfall mindset also leads to known risks being pushed off, delayed, or kicked down the road into the next project. That mindset is just not acceptable in this day and age.
IT projects are just like IT Security ... they're too big and complex to bite off in one chew. The only way you're going to succeed is to cut them up and tackle them as smaller pieces of the puzzle. Get your head wrapped around the idea that the IT world moves quickly and you have to choose a project methodology that matches that pace. Agile is the clear front runner of project methodologies when you're discussing the implications it makes to IT security.
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
By Justin C Miller
Posted 9/1/2014
Projects are a necessity in the corporate world. They provide a means for justification and cost estimation. They give guidance and put standards around big changes. They ensure something is built to be efficient and beneficial and well tested. They provide a means to look back, reflect, and improve for the next time.
Two of the more common methodologies you'll find are Waterfall and Agile.
In waterfall you do things in sequence one after another such as requirements, design, development, testing, and release. In general you end up with large volumes of documentation and a lengthy but thorough process. There tends to also be the risk that you'll build something big only to find out when you pass it off that it's no longer what the business wanted.
In Agile you do all those things, but in small tiny waves. In general you end up with very little documentation but you see results almost immediately. You can eliminate the risk of big surprises because the business is involved during each of those tiny waves.
So, a question you might contemplate is in terms of IT Security, does it matter whether my company is using Agile or Waterfall?
I contend that YES, the choice your company makes for Project Methodology has big implications on your company's IT security. I'll skip the dance and games and get straight to the point ... Agile has become a necessity in the corporate world if you're hoping to ensure your environment is secure.
Agile builds your massively complex software in small tiny waves, perhaps 2-4 weeks at a time.
Here are 5 examples of why Agile promotes a more secure environment than Waterfall ever will ...
1.) In Agile there are fewer features built at a time thus it easier to test, and testing is an important step in finding security vulnerabilities. Imagine being asked to test whether the security groups are configured correctly in your application's 10 administrative screens, each of which have 50 tests cases each. Would you be more likely to get it right if you had to test one of the screens/50 test cases at a time, or if you had to test all 10 screens and 500 test cases at once ? Short and sweet means you can concentrate more and feel less stressed and time constrained and get it right.
2.) There are fewer lines of code to review at a time, thus the peer reviews of the code are going to be done more thoroughly and get a good solid look. I've seen it happen way too many times where in your waterfall project you just get done creating 100's of code files and 1000s of lines of code, and now your code review becomes weak and pathetic ... because you'll NEVER get a developer to review 100's of files and 1000s of lines of code in one shot. But in an Agile scenario it is much more realistic to expect them to view a handful of files and a few lines of code and review it correctly.
3.) One of the key aspects of IT security is code complexity. The simpler the code, the easier it is to secure, the easier it is to understand and the less likely it is to contain a mistake. Thus Agile brings big benefits again because you're writing smaller chunks of code that are less complex and thus by default easier to secure.
4.) Waterfall projects have a history of lasting months if not years from inception till completion. If you've been paying attention to the current state of IT security then you know that things change much quicker than that in our arena. Therefore if you start a project on a certain version of software using certain defense techniques, by the time the project is complete the vendor has probably released numerous software updates, security patches, and even the techniques used to prevent and mitigate vulnerabilities may have changed. Thus by the time a Waterfall project is deployed it's likely already old and out of date and needing an upgrade. Agile on the other hand is pushing out fixes every few weeks and by definition allowing for changing requirements, not just changing business requirements but also changing security requirements. If a patch or vulnerability needs a quick fix, you're able to toss it into the backlog as a feature on the next wave. With Waterfall you'll have a nightmare of a time trying to work it in, and things that get pushed to the backlog in Waterfall typically wait until the project is completely over. Too long in our world.
5.) The biggest, and perhaps least obvious advantage that Agile brings to the table over waterfall is a mindset. You go from moving slow, turning the Titanic, to moving swiftly, piece-mealing it to get the job done quickly. I've seen it many times already where those companies stuck in the mindset of Waterfall are the same companies that struggle to get security patching done because they want to plan it for a month, test it for another month or two, then deploy after a few weeks of Change Advisory board discussions. This of course leaves your company open and vulnerable while you're waiting for the process to play out. The Waterfall mindset also leads to end-of-life software hanging out there because the project is just too large and intense to upgrade ... which obviously is a huge security risk. The Waterfall mindset also leads to known risks being pushed off, delayed, or kicked down the road into the next project. That mindset is just not acceptable in this day and age.
IT projects are just like IT Security ... they're too big and complex to bite off in one chew. The only way you're going to succeed is to cut them up and tackle them as smaller pieces of the puzzle. Get your head wrapped around the idea that the IT world moves quickly and you have to choose a project methodology that matches that pace. Agile is the clear front runner of project methodologies when you're discussing the implications it makes to IT security.
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Subscribe to:
Posts (Atom)