Tag: AppSec

Special Situations

Not all application security programs are the same, and not all security needs are equal. In this article we will compare security for a small family business, a government and Apple.

Think about this: Not only does Apple make two popular consumer operating systems (OSX for desktop and laptop computers and IOS for phones and iPads), they also make a popular cloud platform (iCloud), a popular programming IDE (xCode), hardware for several types of laptops, phones, tablets, watches, and so, so much more. They also build physical security features directly into their products. It wasn’t until I decided to re-publish this article that I realized just how many things depend on Apple. It’s staggering.

What this means is that Apple has very special security needs. Their operating system, cloud and other products that we depend on must be secure. They must go far beyond the average company in their efforts to ensure this, and they do.

 

 

See that computer to my left? It's an Apple. I own 3 laptops that run OSX,
and even used to work at an Apple repair shop back in the day. I learned 
to program on an Apple computer.

But the average company is not Apple. Which means they don’t need to take the same precautions. As a second example, let’s take “Alice’s Flowers”.

Alice has a website for her floral shop that delivers flowers in her small town. It shows basic info, such where they are located, their phone number, and when they are open. It also has a link to her Shopify shop for online orders (meaning she does not need to secure that, Shopify does; Alice is smart to have outsourced the hard part. This is called Risk Transference.). The rest of Alice’s website, in the big scheme of things, is not very important. If her site goes down for a day or two, it would be inconvenient but it would not the end of the world.

Most companies fall somewhere between Apple and “Alice’s Flowers” in regard to their risk. It has been my experience that many places, when I look at where they spend their security dollars, seem to be very confused as to where they sit on this scale. This is not my attempt to make fun or insult any company, I think it’s a sign of our times that not all companies are receiving good (and unbiased) advice.

The AppSec activities listed below do not apply to all IT shops. I invite you, reader, to try to imagine where your workplace would be on this scale. Please remember your place on the scale as you read the rest of these examples, to help you decide if any of this activities may apply to your place of work.

Special AppSec Activities

Responsible Disclosure

Responsible Disclosure (also known as Coordinated Disclosure), is a process where someone finds a security problem in a product or site, reports it to a company, and the company 1) does not sue them 2) thanks them 3) sometimes offers a token of appreciation but generally does not offer money and/or 4) sometimes the person who reported it is publicly acknowledged by the company or their bug is reported formally as a CVE to Mitre.

Last week (when I wrote the first version of this article, in 2019) I used a government website, I saw a bug, I figured out who to talk to (the Canadian Government doesn’t have a disclosure process, of any kind), and I emailed it to them. They said thanks, I offered ideas on how to fix it, and they were great. This is one version of responsible disclosure. See how I was responsible?

Some places have a formal program, whereby security researchers (or normal users like me), can report issues to them in a secure manner (me sending details over twitter then an email to the government employee was not very ‘secure’). If the product they found the issue in is something well-known or used often, they may file a CVE (Common Vulnerability Exposure) so that other’s are aware that version of that product is known to be insecure. But also for credit; having your name on a CVE is pretty cool.

Industry standard for fixing such things is (theoretically) 90 days, but not every company complies, and not every person who reports such an issue is so patient. When you hear that someone “dropped O Day”, what they mean is they released the info about a vulnerability onto the internet, and there is no known patch for it (also known as a ‘zero day’). This is often done in order to pressure a company to fix the issue. Because if one person found it, that means others might have found it (and they may be exploiting it in the wild, causing people problems, and that’s no good).

Note: “dropping O day” is NOT a part of responsible disclosure.

Bug Bounties

Katie Moussouris basically invented Bug Bounties as we know them today, she speaks on this topic often and is a wealth of knowledge on this and many other security topics. Since then several large tech companies have started their own programs including Shopify, Apple, and Netflix.

The invention of bug bounties spawned an entirely new industry; dedicated security researchers or “bug hunters”, as well as large companies that sell these people’s services on a pay-per-find basis.

The thing about working as part of a bounty program is you only get paid if you find something, if no one else has found it before, if your finding is in scope, and if your report actually makes sense. Submitting things that aren’t in scope is a great way to get yourself banned (such as taking over accounts of employees at the company you are supposed to be finding bugs for, don’t do that). What this means is that many, many bug hunters make little-to-no money, and a small few do quite well. I’ve heard people call this “a gig economy”, which means no job security, benefits or anything to fall back on if you have a bad month.

The economics for the researchers aside, this is an advanced AppSec activity. I’ve been asked many times “Should we do a bounty?” to which I have responded “How is your disclosure program going? Oh, you don’t have one, okay. Ummm, how is your AppSec program going? Oh, you don’t really have a formal program you just hire a pentester from time-to-time, okay. Hmmmm, do you have any security-savvy developers that could fix the bugs the bounty finds? No, okay, ummmmm. So you already know that you should DEFINITELY NOT DO A BOUNTY, right? Okay, yeah, thanks.”

I realize that doing a bounty program is “hot” right now, and that the companies that sell bounty programs are happy to tell you that it’s good value for your money to start no matter where you are at in your AppSec program. I disagree. I often sugar-coat things in my blog, but for this I can’t. If you don’t already have an AppSec program and you do a bug bounty program you are setting your money on fire. If you want to hear from an expert on the topic though, you should watch Katie Moussouris explain it much more gracefully than I, here: Bug Bounty Botox Versus Natural Beauty.

Capture The Flag, Cyber Ranges, and other forms of Gamification

Capture the Flag contests, also known as CTFs, are not a bunch of security people running around in a field with flags; it’s a contest made up of security puzzles. Sometimes it is vulnerable systems you need to exploit, sometimes it’s intentional puzzles for you to solve. When you ‘solve’ one of the challenges you get a ‘flag’, which means points. The person or team at the end with the most points wins.

Cyber Ranges and other gamification systems are similar, you play, solve security problems, and learn at the same time.

Why do security professionals sit around playing games and solving puzzles? Because this is a great way to learn. And it’s FUN! Also: if you find a vulnerability and it’s something you have done before in your code you will never, ever make that mistake again. Trust me on that one.

Inviting your developers to participate in security gamification can be a great team building exercise and it can teach them many of the lessons you wish they knew!

Snowflakes

There are many more special situations that demand interesting and exciting AppSec activities, such as chaos engineering, red teaming, and so much more. You can read a lot more about it in my book, Alice and Bob Learn Application Security.

Thank you

Thank you for reading my first blog series; this is the end. When I started my blog I honestly wasn’t sure anyone would read it, but I wanted to share all of the things I had learned so I went for it. Thank you for coming on this journey with me, I hope you follow me on many more.

In my talk that this blog series is based on, “Pushing Left, Like a Boss”, I detailed what I felt an AppSec program should and could be. Since then, I’ve learned a lot and now see that there are quite a few activities that you can do, but it’s the goals and the outcomes that actually matter. Our industry has also changed quite a bit since I wrote that talk (written in 2016, first seen in public 2017, this article first published in 2019 and republished here in 2021).

My first international talk, at AppSec EU, 2017. It feels so long ago.

My previous thoughts on what a basic AppSec Program should be:

• Vulnerability/Security Assessments and VA scans
• Threat modelling
• Secure Code Review
• Penetration Testing
• And that these activities should cover both COTS (configurable off the shelf products, like SharePoint or SAP) and custom apps (homemade software)

For bonus items I had listed:

• Developer education
• Secure coding standards
• Secure Coding Libraries
• Reference materials

And for “extra special situations” I recommended the following (which will be explained in the next blog post):

• Bug Bounty Programs
• Capture the Flag Contests (CTFs)
• Red Team exercises

Anne Gauthier of OWASP Montreal, myself (pre-WeHackPurple) and Nancy Gariché of Secure That Cert and OWASP DevSlop. In the background is Christian Folini of the OWASP CRS project. I had no idea how important these people would become to me at the time.

I’m going to preface this next part with two thoughts.

You can’t do security “right” if you aren’t doing IT “right”. If you can’t publish fixes for a year+ because your processes are broken, if you are underwater in technical debt, if you have dysfunction within your IT shop already, this is going to be very hard. I suggest starting with modernizing your systems and entire IT team as you modernize your security approaches, hand-in-hand. Don’t give up, you can do this! Take one item, aim for it, and continue on until you’re doing well.

If you have poor communications between the security team and the rest of IT this will be another hurdle that you have to work on. Culture plays a big part in ensuring your efforts are successful. I’ve released a bunch of videos on my YouTube channel on this topic, start with this one.

My new vision for an AppSec program:

• A complete picture of all of your apps. Bonus: alerting, monitoring and logging of those apps.
• Capability to find vulnerabilities in written code, running code, and 3rd party code. Bonus: the ability to quickly release fixes for said issues
• The knowledge to fix the vulnerabilities that you have found. Bonus: eliminating entire bug classes.
• Education and reference materials for developers about security. Bonus: an advocacy program, creating a security champion program, and repetitive re-enforcement of positive security culture.
• Providing developers with security tools to help them do better. Bonus: writing your own tools or libraries.
• Having one or more security activities during each phase of your SDLC. Bonus: having security sprints and/or using the partnership model (assigned and/or embedding a security person to/within a project team).
• Implementing useful and effective application security tooling. Bonus: automating as much as possible to avoid errors and toil.
• Having a trained incident response team that understands AppSec. Bonus: implementing tools to prevent and/or detect application security incidents (can be homemade), providing job-specific security training to all of IT, including what to do during an incident.
• Continuously improve your program based on metrics, experimentation and feedback from any and all stakeholders. All feedback is important.

I’d love to hear your thoughts on my new application security ‘prescription’. Please comment below.

Up next in this series we will discuss the AppSec “extras” and special AppSec programs; I will discuss all the things in this article that I have not previously defined for you.

This article is about secure code review and Static Application Security Testing (SAST). Static analysis is a highly valuable activity which can find a lot of security problems, far before you get to the testing or release stages, potentially saving both time and money.

Note: SCA is Static Composition Analysis, verifying 
that your dependencies are not known to be 
vulnerable. I have heard many say "static code analysis" 
when referring to code review/SAST tools, shortening it 
to SCA for simplicity. We will not do that, SCA will only
be used to refer to static composition analysis.

When application security folks say ‘static’ analysis, we mean that we will look at written code, as opposed to ‘dynamic’, which means when your code is running on a web server.

Since I wrote this article a few years ago, I have had a chance to do more in the code review space and spend some time working with SAST tools. Although my attention span is short, and I can be impatient at times (such as, for example, when I am awake), I can now spot several types of problems fairly easily. If you had asked me a few years ago if I would ever find code review pleasurable, I would have laughed, but now I find validating SAST results rather satisfying. It’s funny how much our opinions can change over time.

There are two options for doing code review; manual or with a tool. There are pros and cons to each, and using both will get you the best results.

When reviewing code manually for security you don’t read every line of code; you just review the security controls to ensure they are in all the places they should be and that they are implemented correctly. Although I have not completed hundreds of secure code reviews in my career, I do recall discovering in delight when there was no input validation on a data field, or that an app was not using stored procedures but inline SQL, both of which are big no-nos. It was so obvious when I knew where to look and what to look for. However, most code reviews are not so simple, and many bugs are difficult or nearly impossible to spot with only the naked eye.

Note: when I say “only review the security controls” I mean things like a login, input validation, authorization, authentication, integration points, etc. Anything that has to do with the security of the app.

When using a tool for code review you would use something called a ‘static code analyzer’ or a ‘SAST’ (Static Application Security Testing) tool. This special kind of software parses your code into areas of concern and attempts to follow every possible outcome. It takes a lot of processing power and can take hours or even days to complete. It then creates a report with approximately 60-80% false positives.

Note, since I first wrote this article new types of  
static code analysis tools have been created that 
allow for very fancy grepping (regex searching) of 
the code base, with templates to help you find 
problematic code. How cool is that!

I know what you are thinking right now: 80% false positives !?!?!?! Why would anyone want to use a tool like that? Let me explain.

The key to looking at results of an SAST tool is that the items it lists are not answers, they are hints of where to look for problems, that the code reviewer (hopefully a security expert) can investigate. This means instead of reading 20,000 lines of code, the code reviewer uses the tool, it finds 200 ‘clues’, and then from those 200 ‘clues’ they end up finding 20 real bugs. And many of those bugs they could not have found with just their eyes, because SAST tools can go several layers deep into the code, in a way humans just can’t.

When performing code review it is possible to find all sorts of other problems with your application, not just security issues. During one of my projects the code reviewer found several memory leaks. When we fixed them our application became lightening fast, which made our project team look amazing. There is so much more than just security problems that a good code reviewer can find; it is definitely a worth-while task if you want to build truly resilient and secure software.

Although we already discussed this in Part 5.2 Using Safe Dependencies, I’m going to bring it up again: everyone needs to verify the security of their 3rd party code/components/frameworks/libraries/whatever-you-want-to-call-the-code-in-your-app-that-you-didn’t-write. You must verify that they (3rd party components) are not known to be vulnerable. When I say ‘known to be vulnerable’, I mean there is currently information available on the internet about the vulnerability that is documented on what the problem is and/or how to exploit it.

Many organizations and industry spokespeople create a lot of fear, uncertainty and doubt (FUD) around zero days (vulnerabilities in popular software for which there is no existing patch), advanced persistent threat (APT - someone living on your network for an extended period of time, spying on you) or very advanced attackers, such as nation states. In reality, almost all serious security incidents are a result of our industry not keeping up with the basics; missing patches, people with admin privileges clicking on a phishing email while logged in, and well-known (and therefore preventable) software vulnerabilities, such as using code with known vulnerabilities in it. Essentially; basic security hygiene.

Bonus resource: My friend Paul Ionescu created a code review series.

Up next we will talk about the Testing Phase of the SDLC!

This article will summarize the previous articles in Part 5 of this series, and is hopefully something that you can use for your organization as a start for a secure coding guideline for your developers.

Secure Coding Guideline

• 1. Input validation should be used in every possible scenario. This includes Redirects and Forwards.
• 2. Output Encoding is required for all output.
• 3. Parameterized Queries are mandatory.
• 4. All 3rd party code must be verified not to contain known vulnerabilities.
• 5. Every applicable security header should be used.
• 6. All client-side and browser hardening strategies available to you are required, as outlined here.
• 7. Use the identity and session management features available to you in your framework or from your cloud provider and follow this guidance.
• 8. Take every possible precaution when performing file uploads, including scanning it for vulnerabilities such as AssemblyLine.
• 9. Nothing of any consequence should ever be stored in URL parameters.
• 10. Sensitive data should be stored in secure cookies, and all available security features for cookies should be used.
• 11.All errors should be caught, handled and logged, as per this article. Never log sensitive information.
• 12.Do not trust data, always verify.
• 13.Use the Authorization features in your framework, do not write your own.
• 14.Use the Authentication features in your framework, do not write your own.
• 15. HTTPS only. Use only unbroken and industry standard protocols (currents standard is 1.2 TLS).
• 16. Always use the security features in your framework and never write your own. Always keep your framework up to date.

In order to ensure that your developers are following these 
guidelines, code review is recommended.

I’d like to thank all of my professional mentors and the OWASP volunteers that have taught me about Application Security, that is where and how I have learned the majority of what I know on this topic. Without the OWASP community, and it’s free and vendor-neutral teachings, many of us would not be where we are today. The OWASP community has my unwavering and unending gratitude and support. Thank you.

Special thanks to the following people who have helped me directly in learning these concepts, and so much more: Dominique Righetto, Jim Manico, Sherif Koussa, Adrien de Beaupre, Sonny Wear, Nicole Becher, Chenxi Wang, Zane Lackey and Kim Tremblay. I’d never have gotten this far without them.

If you like this blog series, you will love the OWASP Cheat Sheet project! My favorite OWASP project of all time. Check it out!

Up next in part 6 we will discuss the testing phase of the SDLC, what types of security testing we can do, the approaches we can take, as well as other strategies and phases within the SDLC that we can test our apps.

Do you have any more secure coding principles that you would like to add? Guidance you’d like to share? Please add it to the comments below!

HTTPS only — for every app, everyone, always.

Temple in South Korea, 2019, Photo Credit: Bryan Hughes

Now that encryption is fast, and free, and we know the risks of not using it, there is literally no excuse not to use HTTPS only for every application on the Internet. Literally every application, even for static pages that contain no sensitive information. For everyone (there is no class of user that does not need protection on the internet). Always (there is no time limit, and you can auto-renew your certificates; you don’t even need to really think about it).

Every public website and web application (including APIs) should force the use of HTTPS (and disallow or redirect connections using HTTP). This can be done using security headers in your code or forced on the server.

There is no reasonable excuse for not using HTTPS only for public-facing applications. Feel free to argue with me in the comments. 😀

Up next we will summarize “Part 5: secure coding” of this series.

Note: much of this comes from the OWASP Cheat Sheet on Access Control, by Shruti Kulkarni, Adinath Raveendra Raj, Mennouchi Islam Azeddine and Jim Manico. And if not, it may come from one of the other offerings from the amazing OWASP Cheat Sheets Project. For more information on almost any AppSec topic, check out the project, it’s definitely worth your time!

B-Sides Vancouver, 2019

Let’s start with some definitions.

Authentication is ensuring that the user who is using the application is the actual person they purport to be. For instance, when I log into my webmail, it verifies that I am the one-and-only Tanya Janca that owns this account. Not a different person who is also named “Tanya Janca”, and not someone pretending to be me. The real, authentic, me; the person who owns the account.

Identity (digitally speaking) is a hardware or software-based solution for proof of identity of citizens, users or organizations. For example; in order to access benefits or services provided by government authorities, banks or other companies in person, you must verify your identity, usually with a driver’s license, passport or another physical document. However, if you are verifying your identity digitally (electronically), you must use a software or hardware based solution to prove your identity.

Access Control is allowing (or not) users to access systems, features, data, etc. based on the permissions that the system has assigned to that user. For instance, perhaps you have access to the main parts of your building, but there is an electrical room to which you do not have access. Your badge will not get you it. This is access control, and it works the same way with software, granting or restricting access based on your role and/or identity within the system.

As usual, I recommend using the features as provided in your programming framework for AuthN, Identity and Access Management features. I also suggest strenuous testing of your implementation, because if someone breaks these security controls there shall be dire consequences.

General Rules of Authentication (AuthN)

• Applications that use password-based authentication should follow the standards put forth in my book, Alice and Bob Learn Application Security and/or the current NIST Password Standard. Ex: do not forces users to change their passwords often, allow very long passwords, do not force complexity, allow and encourage the use of password managers, etc.
• The principle of least privilege is the practice of limiting access to the minimal level that will allow normal functioning. This principle should be applied not only to the users of web applications, but to the applications themselves, and as they are given access to databases, web services and other resources. For example, it is rare that an application requires a database user that is the database owner (DBO); generally, read/write or CRUD is enough.
• Passwords will be salted and hashed (one-way), not encrypted (two-way), before storing. Use a strong hashing algorithm (again, refer to my book, Alice and Bob Learn Application Security or NIST if you are unsure).
• Passwords will be encrypted in transit (HTTPS only).
• Re-authentication will be performed for “Sensitive Features”. Sensitive features could include, but are not limited to; changing passwords or security questions, changing bank account information, deleting a user account, transferring large sums of money.
• Measures must be taken to prevent or circumvent brute force attacks. Measures could be a maximum number of login attempts, requiring a captcha after 5 failed logins attempts or throttling (slowing down) the system to make a brute force attack more difficult.
• Passwords must be masked (not echoed to the screen) while the user enters the password.
• Validate that a user is authorized to access every new page and for every action. Ensure that this is applied using a pre-approved list of approved users, not a block list of unapproved users. See blog post Pushing Left 5.1 for more information on input validation and approved lists..
• Never assume that “hiding” a page or feature means that it is protected or ‘safe’, that is not enough.
• Login fails and errors should be logged. Ensure not to log sensitive information such as the text used for the attempted password, as it is likely only one or two characters off from the real password. Refer to blog post Pushing Left 5.9 for more information on what to log.
• Brute force attempts (defined as 10 or more successive failed attempts to login in under 1 minute, or 100 or more failed attempts in one 24-hour period) must also be logged. If possible, the IP address of said attacker should be blocked, and account owner notified.

I realize that this list is not exhaustive, as this is a huge topic that could easily fill an entire book. I invite you, my readers, to provide more thoughts, topics and ideas in the comments section below. Thank you for reading.

Up next in the ‘Pushing Left, Like a Boss’ series: HTTPS only.

 

Authorization (also known as ‘AuthZ’) is verifying that the user who is trying to perform an action within your application is allowed (is authorized/has permissions) to use that functionality. For instance, is the user an admin user? If so, allow them to view the admin page. If not, block access.

There are several different models used within our industry for authorization, with RBAC (Role Based Access Control) being the most popular. RBAC means assigning people different roles in your system(s), just like people play different roles within your organization, and give them access based on the role they are assigned.

For instance, meet Angela, a hypothetical software developer who is new to my project team (pictured below).

#WOCTechChat: Angela the Software Developer

 

As a software developer Angela is going to need access to all sorts of things; source control, perhaps permission to publish to the CD/CI pipeline, and various file systems.

Now look at the second image to see our project team: Sarah, Angela and Jennifer. A project manager, software developer, and a database administrator (DBA). They all play different roles within the project and our organization, so they need different sets of permissions and access. Angela the software developer should not need Database Owner (DBO) permissions, but the DBA definitely will. The project manager is unlikely to need access to the web server.

This is where Role-Based Access Control (RBAC) is extremely helpful, the system administrator can easily assign the proper roles to each of our project members, to ensure they are only authorized access to the things they need to get their jobs done (least privilege).

Project manager, software developer, and DBA, Photo Credit: #WOCTechChat

When writing code for authorization within applications, use the features in your framework, and re-verify access for every feature and/or page of your application. Test your implementation thoroughly, with each role, for best results.

This is something that is often gotten wrong by software developers, which can cause huge issues, so please take care to do thorough testing.
For a deeper dive into this topic, check out the OWASP Cheat Sheet on Authorization Testing Automation, by Dominique Righetto.

Up next in the ‘Pushing Left, Like a Boss’ series: Authentication (AuthN), Identity and Access Control.