Framework Security with Ksenia Peguero: the paved road foundation

In this episode I’m joined by Ksenia Peguero, Sr. Research Lead at Synopsys, for a discussion around frameworks and the foundational effect they have on the security of your application. We’ll share concrete tips for upgrading your security through your framework, choosing the best framework for app security, performing a framework migration, and how to spot and fix security blind spots in your frameworks.
Resources:
About Ksenia
Ksenia Peguero is a Sr. Research Engineer within Synopsys Software Integrity Group, where she leads a team of researchers and engineers working on static analysis and security of different technologies, frameworks, languages, including JavaScript, Java, Python, and others. Before diving into research, Ksenia had a consulting career in a variety of software security practices such as penetration testing, threat modeling, code review, and static analysis tool design, customization, and deployment. During her decade in application security, she performed numerous engagements for clients in financial services, entertainment, telecommunications, and enterprise security industries. Throughout her journey, Ksenia has established and evolved secure coding guidance for many different firms, developed and delivered numerous software security training, and presented at conferences around the world, such as BSides Security, Nullcon, RSA, OWASP AppSec Global, TheWebConf, and LocoMocoSec. She has also served on review boards of OWASP AppSec USA, EU, and Global conferences.
https://www.linkedin.com/in/kseniadmitrieva/ (https://www.linkedin.com/in/kseniadmitrieva/)
https://twitter.com/kseniadmitrieva (https://twitter.com/kseniadmitrieva)
Ksenia Presentations:
https://www.youtube.com/watch?v=Ku8mPXmX7-M (https://www.youtube.com/watch?v=Ku8mPXmX7-M)
https://www.slideshare.net/kseniadmitrieva/how-do-javascript-frameworks-impact-the-security-of-applications (https://www.slideshare.net/kseniadmitrieva/how-do-javascript-frameworks-impact-the-security-of-applications)
Additional Resources:
Passeport, Flask login
http://www.passportjs.org/ (http://www.passportjs.org/)
https://flask-login.readthedocs.io/en/latest/ (https://flask-login.readthedocs.io/en/latest/)
Sails CSRF protection
https://sailsjs.com/documentation/concepts/security/csrf (https://sailsjs.com/documentation/concepts/security/csrf)
Express CSRF plugin
https://github.com/expressjs/csurf (https://github.com/expressjs/csurf)
Django / React security pagehttps://docs.djangoproject.com/en/3.1/topics/security/ ( https://docs.djangoproject.com/en/3.1/topics/security/)
https://guides.rubyonrails.org/security.html (https://guides.rubyonrails.org/security.html)
Ksenia Angular listing ruleshttps://github.com/synopsys-sig/tslint-angular-security ( https://github.com/synopsys-sig/tslint-angular-security)
W3C security WG
https://www.w3.org/2011/webappsec/ (https://www.w3.org/2011/webappsec/)
Levels of vulnerability mitigation: https://image.slidesharecdn.com/javascriptframeworksecurity-amsterdam-191008173330/95/how-do-javascript-frameworks-impact-the-security-of-applications-7-638.jpg?cb=1570556143 (https://image.slidesharecdn.com/javascriptframeworksecurity-amsterdam-191008173330/95/how-do-javascript-frameworks-impact-the-security-of-applications-7-638.jpg?cb=1570556143)
Episode 2 Transcript:
[00:00:02] Welcome to App Sec Builders, the podcast for practitioners building modern AppSec hosted by Jb Aviat.

Jb: [00:00:10] Hello Ksenia, nice to meet you

Ksenia: [00:00:14] Hi, Jb, how are you doing? 

Jb: [00:00:20] I'm great, thank you. So, Ksenia, you're a senior research engineer at Synopsis.

Jb: [00:00:24] You led a team of researchers and engineers working on static analysis. Before Synopsys. You've had a consulting career where you did penetration testing, threat modeling, code review, and you are also a seasoned speaker at various app security conferences across the world, such as the famous OWASP AppSec. So could you tell...

In this episode I’m joined by Ksenia Peguero, Sr. Research Lead at Synopsys, for a discussion around frameworks and the foundational effect they have on the security of your application. We’ll share concrete tips for upgrading your security through your framework, choosing the best framework for app security, performing a framework migration, and how to spot and fix security blind spots in your frameworks.

Resources:

About Ksenia

Ksenia Peguero is a Sr. Research Engineer within Synopsys Software Integrity Group, where she leads a team of researchers and engineers working on static analysis and security of different technologies, frameworks, languages, including JavaScript, Java, Python, and others. Before diving into research, Ksenia had a consulting career in a variety of software security practices such as penetration testing, threat modeling, code review, and static analysis tool design, customization, and deployment. During her decade in application security, she performed numerous engagements for clients in financial services, entertainment, telecommunications, and enterprise security industries. Throughout her journey, Ksenia has established and evolved secure coding guidance for many different firms, developed and delivered numerous software security training, and presented at conferences around the world, such as BSides Security, Nullcon, RSA, OWASP AppSec Global, TheWebConf, and LocoMocoSec. She has also served on review boards of OWASP AppSec USA, EU, and Global conferences.

Ksenia Presentations:

Additional Resources:

Passeport, Flask login

http://www.passportjs.org/

https://flask-login.readthedocs.io/en/latest/

Sails CSRF protection

https://sailsjs.com/documentation/concepts/security/csrf

Express CSRF plugin

https://github.com/expressjs/csurf

Django / React security page https://docs.djangoproject.com/en/3.1/topics/security/

https://guides.rubyonrails.org/security.html

Ksenia Angular listing rules https://github.com/synopsys-sig/tslint-angular-security

W3C security WG

https://www.w3.org/2011/webappsec/

Levels of vulnerability mitigation: https://image.slidesharecdn.com/javascriptframeworksecurity-amsterdam-191008173330/95/how-do-javascript-frameworks-impact-the-security-of-applications-7-638.jpg?cb=1570556143

Episode 2 Transcript:

[00:00:02] Welcome to App Sec Builders, the podcast for practitioners building modern AppSec hosted by Jb Aviat.

Jb: [00:00:10] Hello Ksenia, nice to meet you

Ksenia: [00:00:14] Hi, Jb, how are you doing? 

Jb: [00:00:20] I'm great, thank you. So, Ksenia, you're a senior research engineer at Synopsis.

Jb: [00:00:24] You led a team of researchers and engineers working on static analysis. Before Synopsys. You've had a consulting career where you did penetration testing, threat modeling, code review, and you are also a seasoned speaker at various app security conferences across the world, such as the famous OWASP AppSec. So could you tell us a bit more about you and what you enjoy in the AppSec field?

Ksenia: [00:00:49] Sure. Well, I come from an engineering background. I was an application developer in the gaming industry for about five years. And then I came to the United States to do my masters.

Ksenia: [00:01:01] And the last year I got an internship with Cigital that used to be called Cigital, a consulting company as a security intern. And I never went back to development. That was absolutely fascinating career because as a consultant, as a security person, you always need to learn new things. So I did consulting for about seven years and kind of went up into the ranks of principal consultants. And then I pivoted and started to dig more into the research and security research. And around the same time Cigital was acquired by Synopsys. So now I work in Synopsys. So pretty much with the same company, with the same people, with a different name. But now as part of the security research lab, as a security engineer.

Jb: [00:01:47] Super cool. You mentioned the gaming industry. Ksenia, so did you develop anything popular, famous?

Ksenia: [00:01:55] Well, that was many, many years ago and I was developing games in Flash. Adobe Flash.

Jb: [00:02:03] Oh, my God.

Ksenia: [00:02:04] So, you know, the little match, three type Tetris type games for housewives and people at work.

Jb: [00:02:13] All right. That could be a nice introduction. Yes. That's how I got into security by hacking flash in the browser, but maybe not.

Jb: [00:02:24] Ok, and so you were actually in the middle of a PHD thesis, right?

Ksenia: [00:02:29] That's correct. Hopefully closer to the end. But yes, in parallel with my full time job, I'm also doing a PHD and I'm working on guess what? Security research and on framework security specifically.

Jb: [00:02:45] And so how do you feel academic research is helping application security moving forward today?

Ksenia: [00:02:51] It's interesting. I feel like - because I have a lot of experience in the practical field, I hope - I feel that I bring a different perspective into the academia because a lot of the research that there is and academia, at least in the last 10 years, a lot of the research was focusing on exploits, on finding vulnerabilities, which is great because people in academia spend a lot of time, you know, finding those new vulnerabilities, new types of attacks, especially on more complex concepts like crypto attacks, for example.

Ksenia: [00:03:25] But until about now, academia wasn't focused much on fixing the problems that they find. So with my background in security consulting, where we not only find the issues, but we help developers to fix the issues, that's what I'm trying to bring into my research. How do we actually get rid of the bugs and not just find the bugs?

Jb: [00:03:47] Yes so basically more shifting left, right?

Ksenia: [00:03:51] Exactly. Yeah, exactly.

Jb: [00:03:53] So helping academia futures shift live to great outcomes here. So this extensive research that you've done on frameworks, so you presented it recently at AppSec Cali. So in your research, you found that some frameworks made it easier than others to introduce certain categories of vulnerabilities. So would you mind telling us a bit more about that?

Ksenia: [00:04:15] Sure. So as part of my research, I was focusing on JavaScript and I started with the client-side JavaScript frameworks or template engines, and then I switched into server-side JavaScript frameworks and I looked at different vulnerabilities.

Ksenia: [00:04:30] And the hypothesis was that if the framework actually has security controls or mitigations built-in, then the applications would be more secure than if they're not. So it's kind of a native idea. But with the help of the categorization framework developed by John Steven, I divided the places where the mitigation can exist into different levels. So we start with a level zero where there is no mitigation and code is vulnerable. And oftentimes that happens when there is no framework in use at all. So everything is written by developers from scratch and then we go into the next level of a custom function that developer has written and then into a third party library that developer is using and then into a framework plugin, so something that works very tightly with a framework and then the next level of the mitigation is built into the framework. And then actually there is another level that I discovered throughout my work is when the mitigation is built into the language, programming, language or platform itself. And of course, as far as you go closer to the framework or closer to the architecture level, those vulnerabilities will be fixed and it's less likely that they will actually appear in the applications. But we also need to remember another important thing that again, I discovered comparing the applications and running different security tools on them is that it's not just the built-in mitigations, but also the defaults are important. So if something is built into the framework but not enabled by default, then developers may not even know it exists or may not enable it, or they may be disabled or they need to enable it in a test environment. And then it never got enabled when the application transitioned in production.

Jb: [00:06:21] Yes. And so you actually prove by analyzing actual applications that I think it was CSRF protections that were not enabled by default.

Ksenia: [00:06:32] Yeah, exactly. So I took several server-side JavaScript frameworks, Express, Koa, Hapi, Sails, and looked at which level each of this framework has the Cross-Site Request Forgery protection enabled if, for example, Express and Koa have plugins. So it's an extra step that developers need to go find the plugin, turn it on, and enable it correctly with correct settings versus Sails, for example, has it built-in, but it wasn't enabled by default. So when I tested about like 500 applications on GitHub and compared them based on the framework, I actually could see that the number of applications that have Cross-Site Request Forgery in Express, for example, is the same as in Sails, which that wasn't what I expected. But when I was digging deeper, most often it was the case that in Sails that protection was not enabled. It was just set to false by default.

Jb: [00:07:34] So that's an interesting outcome and so our data at Sqreen concurs with that.

One thing we have seen is that amongst Sqreen customers, I've seen that applications without frameworks are 7 times more likely to have vulnerabilities than applications with a framework. That is something like - I'm a former pentester and so at the beginning of my career, I witnessed how Ruby on Rails grew in popularity and helped popularize development best practices across the industry. So it really was a game-changer at the time. As Rails popularized MVC templating engines, database migrations, object-relational mappers, convention over configuration. So it wasn't perfect, but it was such a huge step forward that we really witnessed the quality of Web applications changing. And so did you experience the same thing, like some frameworks drastically improving the security of some applications?

Ksenia: [00:08:33] Yeah, yeah, it's fascinating. If we look at the OWASP top 10, as I was researching specifically, Cross-Site Request Forgery. If we'll look at the OWASP top 10 in 2003 and 2009. CSRF was in the top 10, right. Higher up like fourth place than seventh place. And then it was starting to gradually go down. And then in the recent one, it's not even there. It's not present. And the reason for that is that because a lot of frameworks has CSRF protection enabled by default. And sometimes it's not that it's some sort of security feature that they built-in. I mean, it is kind of on purpose, but it's just the way the framework built. So, for example, if we look at .Net, ASP .Net, they have a view state that they save for every page. And so if the content of the page changes, it's like a signature of the page. Right. So if the content changes, for example, if an attacker is trying to inject a request and doesn't have a CSRF token in it, then the request will not be accepted just because the page was crafted by an attacker and it looks slightly different. So basically it's a CSRF protection as long as that view state is signed so that attacker cannot fake it as well. But yeah, basically some of such big frameworks also Spring Security, for example, has that enabled by default for all POST and DELETE requests. So since it's enabled by default, developers don't need to think about it and it just stops being an issue.

Jb: [00:10:09] Yes, yes. The view state is famous indeed, it reminds me of there were actually a vulnerability in the view state implementation. You said it's signed and I remember back in the days they were padding Oracle vulnerability in, I think it was like Liferay, one of the .Net frameworks, And so basically you could just basically generate or recover the signature for anything. And just you had the remote code execution by just managing to fake the actual state. That was a small one but a fun one. Padding Oracle attacks are amazing in theory. And when you have one that works in practice, it's always a good achievement. Exactly. So, yes, very good example. And so you mentioned about the levels of vulnerability mitigation by John Steven. So that's a concept that I didn't know and that I discovered in you in your OWASP Cali presentation. Really interesting. So I will share an illustration in the episode resources. So I think it can help us categorize the frameworks because so you have frameworks that tend to be very simple, very modular, such as Express, Flask or Sinatra. And you have so they have very little out of the protection for common threats because they give a lot of freedom to the developer and it's up to the developer to choose what they want to use and how they want to use.

Jb: [00:11:32] So amazing performance because they do very little out of the box. And on the other hand, you have much more elaborated frameworks such as Sails, Django, Ruby on Rails, that have many, much more out of the box pieces. And so there are like several ways to add security constraints, either relying on the team or library. So like the team would push their own library to add their own controls. That would be level 1 according to the classification. Maybe it would be a very well known library, like Cerberus or Joy in Node, level 2, or a framework plugin, level three, etc.. And so your research showed that the closer to the frameworks you are and the ultimate being, having this mitigation of this library built into the framework, the best level of security would be achieved. So if we assume that someone wants to pick a framework for a project, so usually security isn't the main driver to deciding what piece of software you want to use. Security is only one dimension amongst others when you evaluate a framework. So how would you recommend evaluating the security of a framework?

Ksenia: [00:12:42] Yes, I wish security was important, important for developers when they take it from the start. Right. But of course, I mean, we choose a framework

Jb: [00:12:50] I wish security was more important for frameworks developers, Ksenia. But it's unfair, It's more and more true.

Ksenia: [00:12:58] Right. But yes, when we choose the framework, we'll look at performance, at functionality doesn't actually solve. Our problem is that MVC framework is a rest framework. Like what is the problem we are trying to solve and then is it popular? Is there the documentation? And then with somebody will say, oh, what about security of the framework? And I actually have a story about that.

Ksenia: [00:13:19] So when I was a consultant, we had a client, a big financial industry organization, and oftentimes such companies are not quick in accepting new technologies. They like things that are proven and tested. So they would use .Net and Java and with JSP for the front end. I mean, that was a few years ago, quite a few years ago. And so the front end developers wanted to switch into using Angular and just management was like, well, what is the security impact if we're switching all our front end development into Angular? So they hired us to answer that question. And being the security-minded person, I dig into Angular and found a bunch of ways that you could exploit and different security vulnerabilities. And frankly, Angular is a very secure framework. Right. So there are not many ways compared to other things. But of course I did my best and came up with this presentation and show it all the way is how Angular can be hacked.

Ksenia: [00:14:21] And the management were all very frightened. I was like, oh my God, this is so insecure. We should have new security protocols, new manual code review steps or anything else if we want to introduce that and actually no. Right, it's still a front end framework. It still has the same issues as your JSP or another templating engine. It's still going to be vulnerable to cross site scripting and other like iFrame bypasses, etc.. So from the protocols, from the policy standpoint, it's no different. But actually Angular is a pretty secure framework because if you look at the documentation, A. they have like a security page that's separate in the framework documentation not many front-end frameworks have a security section in them, and they made an effort to mitigate as many vulnerabilities as possible.

Ksenia: [00:15:19] So, for example, Angular has the contextually aware escaping that is built into the framework it has the way to enable the CSRF protection if it's also enabled on the server-side and have the service and the clients that talk to each other and some of the tokens, et cetera. So, yes, it's great to look at the security of the framework. And as a developer, I mean, of course, maybe you cannot go and actually test the framework and evaluate, OK, what are the security issues with it. But you can definitely look into the documentation, see if there is a security section in it. You can look at the release notes and see what kind of bugs were fixed in the last few versions of the framework. Like were there things that were fixed that have to do with security? If it's an open-source framework, you can go to their GitHub and look at the issues. What kind of issues were reported? Are there a bunch of security issues that were reported and...