 Hello, good afternoon. So first of all, thank you for RubyConf talent for giving me this opportunity to talk here. So today, I would like to talk about security issues on your Python, oh, sorry, on your Ruby code. And let me introduce myself. I'm Harley Davidson. It sounds weird. It sounds like the motorbike. And I'm working as security program manager for application security firm. Singapore based, but I'm working for Jakarta region. It's called Funtouch Point Security. So I manage how the client rolling out the application security program end to end from the requirement design, development, and until to the deployment. So coming from Jakarta Indonesia, you can reach out to me at Twitter, at Harley-David, car one. No wonder it's hard for me to use Harley-Davidson in the Twitter account because it's already used. And today, I'm going to tell a story about the finding security issue on development stage using open source static application security testing. Is there anyone familiar about the term? So is there anyone coming from the security background? Yeah, we have one there. OK, so I'm going to talk about the static application security testing in the back. So the goal is the developer can identify security issues on earlier stage without waiting for application through penetration testing. Is there anyone knows or ever heard about penetration testing? Yeah, a lot. So penetration testing is a stage where we literally hack our application to measure to find whether the app contains security issues or not. And this is about the common development process. The common development process starts from the requirement, design development testing in UAT and after that going through the production stage. Ideally, in every stage of a development stage, ideally there must be security touch point involved in every stage of a development stage. Because like I mentioned earlier about the penetration testing, if we take a look on this picture, penetration testing is taking part in the end of the development stage. Means we need to wait for the application being created before we're doing some security assessment. Meanwhile, security issues could be created on the earlier stage, such as on design phase and development phase as well. And what happened if we only put security assessment on the final stage? After we found the security issues, we need to roll back the process coming through from the requirement, doing some design, and develop again. And after we fixing for the first time, there is no security issue there and there is no security measurement. And again, on the final stage, we're doing penetration testing and then we found the security issue and then it's coming back to the first stage. So it's kind of like circle loop of the remediation cycle. There is a research artifact which said that the comparison of cost to fix security issue based on time of detection. So it's the research coming from NISD. So NISD said that if we found the security issues on the acceptance testing, it will be 15 much expensive rather than if we found immediately on the earlier stage. So it's for the management point of view perspective. It will be costly hire if we put security assessment in the final stage of development because we need to spend more budget to redevelop, to redesign, and fix all of the stuff. And I was mentioned about security issues. So in my opinion or in some of literature said that security issues coming from two different kind. The first one, the coming from the design flows. Design flows like there's no RBIAC implementation. Like let's say the regular employee able to invoke the supervisor function in the application, something like that. And the other one is coming from the coding box. So today we're going to talk more deep about the coding box. Not really deep, actually. So SQL injection is one of them. Any familiar about SQL injection? Yeah. So I quote from the internet that SQL injection is application vulnerability that occurs when untrusted data is inserted in a SQL query without any sanitation or escaping. So this is how it looks. If this particular line of code invoke with name FFF, the resulting query will be like this one. But if it's set to double quote, single quote, or one equal one, single quote one, the query will be like this one. The tag is the successful inclusion of an OR operator which help us return all the records from the database. And this is how SQL injection can be fixed. SQL injection is not possible when using the above because the first element of the array is a template and letters are parameters to the template. And for the second one, it can be used for the fixing SQL injection as well. So maybe I can show a little bit demo of SQL injection itself. So regardless to the programming language, I clone this sample project from GitLab. It's coming from Jason. Jason something. Thank you for him to make these simple apps. So it's basically, let's pretend it's an online store when we can search for something like water. Maybe we can type juice. What if we put, it will dump the database, the username, and the hash password of it. Yeah, I hope this kind of demo can give us more visibility to understand what is the SQL injection. Let's get back to the slide. Where's the slide? This one. And then what else besides SQL injection? There's a lot of which we can consider as a security issue. And for you guys, if you like deep more about the security issue, I would like to recommend you to visit the OAPS pages. So OAPS stands for Open Web Application Security Project. This is non-profit organization. Annually, they make 10 most critical web application security risk for each year. So let's say I take a sample. This is the top 10 security issue at the 2017. So because previously, we only talked about SQL injection. So OAPS itself categorized into several categories, like injection, broken authentication, and ETC. You can find it by yourselves at oasp.org. And how to make sure the code doesn't contain security coding bugs. So this is for the developers. So mostly of the developers, they don't think carefully about how to write in secure code. Is there any of you who has secure developer courses or secure development program? Nope. If that the case, I hope this topic will much easier help for you guys. And so how the developer can able to identify whether he writing the code securely or not. There is a tool called static application security testing, or commonly known as SAS. So SAS is designed to analyze source code and our compiled version of code to help find security flows. In this case, the flows which caused by coding bugs. Since today, we are in Ruby conference. So there is a tool for SAS. It's open source tool. It's called with Brackman. Has anyone used Brackman before? So I think it should be enough. Because everyone knows Brackman, so there's no point for me to continue the speech, right? So it's open source tools. We can use it for scan the Ruby on Rails application. It's statically analyzed race application code to find security issues. We can find it on the github.com slash president beef slash Brackman. So Brackman installation itself, it's not quite hard. We can install using Ruby games, using Bandler, or we can use the Docker version as well. And for the compatibility, Brackman should work with any version Rails from 2.3 to 5. something. Brackman can analyze code write-on with Ruby 1.8 syntax and newer, but requires at least Ruby 2.3.0 to run. And Brackman itself has several capability to find security issue on the coding box level, such as cross-site scripting, SQL injection, command injection, cross-site request forgery, and many more. And Brackman output format, it can be CSV, JSON, text, HTML. We can choose our preferences, whichever we want. And Brackman itself able to integrate with Jenkins. So if you guys using Jenkins for the CI CD orchestrator, we can integrate the Brackman into the CI CD pipeline as well. Because the Brackman has its plug-in for Jenkins. And maybe I can show you a quick demo about the Brackman usage. So I clone some Rails project. It's called with Rails Goat. So it's kind of like vulnerable apps for a base on Ruby on Rails. This is the Rails Goat project looks like. And for using Brackman, we can simply using this command. It's simple as Brackman and the project route. And we can type enter. She'll be working. And the result will coming through. And for a better user interface, we can convert it to certain file, like I mentioned earlier, to HTML. Maybe it's better if we put it to HTML. So HTML. So this is how the Brackman report looks like in HTML format. So first, it tells us the application path, which already being scanned. This is the path. And it tell us the information about the Rails version and the Brackman itself version. And it tell us what is being checked from Brackman. So we can see it's checked for basic authentication, JSON parsing, SQL, XSS, and et cetera. So if you take a look on here, it's coming with the warning type. Warning type, it's represent how many security issues which found on the application. It's already categorized based on this category, common injection, cross-site request forgery, SQL injection, et cetera. So in the next table, it tell us about the class, dashboard controller, the method, and then the warning type, let's say, for the SQL injection. And it's coming with the code snippet as well. For this one, we take a look for the SQL injection. And it tell us exactly the line number which potentially contains SQL injection. And it's provide us the link for the further info. If we click on the link, it will direct to the Brackman site and will tell us what is SQL injection and give us the suggestion how to fix it. I think that's a quick demo for the Brackman. Maybe for the next, there's a bundler audit. This is used for checking for the authorization of games in game file log. We can clone from github.com, rubysec, bundler audit. So maybe I show you the quick demo. So the comment is as simple as that, like just bundler hypen audit. And the result will come. It will tell us the Rails God application is using Nocogiri dependencies using version 1.10.2. And it has security issues with the high critical. And it's already listed on the vulnerable database library with CVE 2019, 5477. And this is the URLs. And this is the title. So this is the solution to upgrade from this version to this version to avoid the security issue. And as simple as that. And then what else do we have? I think that's all that I have. So just for the disclaimer, I'm not the ruby expert. I'm not kind of like hands-on guys on the ruby. But I'm still learning ruby. So if you have any question regarding to this, please don't hit me with the hard one. I think thank you. OK, we do have one question here, which is what are the most common security issues you see which Rails doesn't cover by default and Breakman doesn't catch? So basically, for figure out the security issues, it depends on the capability of tools itself. If we are talking about the security issue which caused by the coding bugs. So coding bugs mean we write the code. So if the question, what is the security issue which is not exposed by the hardest one, to be honest, I can't answer that kind of question, but my answer is it depends back on the tool. So as long as the tool has the capability, has the set rule to identify the certain bugs, it always catch by the tools. OK. OK, so I hope that's my help. Yeah, that's great. Thank you very much. Yeah, because the tools itself working based on the rule set. So for the example, for the school injection or another common security issue, the tools has the capability because it registered the rule set to identify those vulnerabilities. So if one day the new vulnerability occurs and for the current tools, it's not update the rule set, it's high probability that the tools could not identify the issue by itself. OK, thank you very much to Harley-Davidson. Thank you.