Ask HN: What's the best programming language to learn for security?
24 comments
Depends on what type of security you want to get into.
General Pentesting: Python or something higher level. Lots of library and tool usage (i.e. scapy, nping, nmap, metasploit)
Application Security: Learn frameworks more than languages. How to work inside of Rails, Spring, ASP, PHP stuff, etc. Common security bugs that exist in these codebases, how to fix them, and how to recognize them. It is more important here HOW things work not how to make really big things work. There are tools that you need to know how to use too, like Burp or some kind of HTTP proxy.
Exploit Development/Reversing: Goes without saying you need to know C very well. You also need to know Assembly very well and how to navigate around the OS. How windows exploits work from the basics like finding kernel32.dll to bypassing ASLR and other types of exploitation techniques. Fuzzing, etc. This probably has the highest bar of entry.
Your side note, how many programming languages do you need to be successful. The answer is a minimum of 1 if you know everything about it. You can add a lot of value doing things like AppSec Consulting for Java if you know a ton about securing Java frameworks.
You can email me if you have any questions. I love talking security
General Pentesting: Python or something higher level. Lots of library and tool usage (i.e. scapy, nping, nmap, metasploit)
Application Security: Learn frameworks more than languages. How to work inside of Rails, Spring, ASP, PHP stuff, etc. Common security bugs that exist in these codebases, how to fix them, and how to recognize them. It is more important here HOW things work not how to make really big things work. There are tools that you need to know how to use too, like Burp or some kind of HTTP proxy.
Exploit Development/Reversing: Goes without saying you need to know C very well. You also need to know Assembly very well and how to navigate around the OS. How windows exploits work from the basics like finding kernel32.dll to bypassing ASLR and other types of exploitation techniques. Fuzzing, etc. This probably has the highest bar of entry.
Your side note, how many programming languages do you need to be successful. The answer is a minimum of 1 if you know everything about it. You can add a lot of value doing things like AppSec Consulting for Java if you know a ton about securing Java frameworks.
You can email me if you have any questions. I love talking security
I actually don't think you need to know assembly all that well to do exploit dev and reversing. What you need is:
(a) native-level proficiency with C and the memory hierarchy that C tries to abstract (ie: you want to understand what goes in registers, when, and why, and how a stack frame is laid out and why)
(b) at least limited working proficiency with compiler theory, most especially the analysis of control flow graphs
As time goes on, knowing little working-programmer details like how LEA gets used for multiplication is getting much less important, and understanding compiler IRs (particularly LLVM) is getting more important. Weirdly (but awesomely), both exploit dev and reversing is becoming more and more theoretical (predicate translations and satisfiability, symbolic execution, &c) and less and less systemsy, and the systemsy stuff is getting larger-scale: like, writing whole-system emulators to reverse firmware targets.
I guess my argument would be: you don't ever need to learn how to write a decent assembly program to get to (a) and (b), and by the time you have (a) and (b), you'll easily be able to pick up whatever assembly you need as you go.
(a) native-level proficiency with C and the memory hierarchy that C tries to abstract (ie: you want to understand what goes in registers, when, and why, and how a stack frame is laid out and why)
(b) at least limited working proficiency with compiler theory, most especially the analysis of control flow graphs
As time goes on, knowing little working-programmer details like how LEA gets used for multiplication is getting much less important, and understanding compiler IRs (particularly LLVM) is getting more important. Weirdly (but awesomely), both exploit dev and reversing is becoming more and more theoretical (predicate translations and satisfiability, symbolic execution, &c) and less and less systemsy, and the systemsy stuff is getting larger-scale: like, writing whole-system emulators to reverse firmware targets.
I guess my argument would be: you don't ever need to learn how to write a decent assembly program to get to (a) and (b), and by the time you have (a) and (b), you'll easily be able to pick up whatever assembly you need as you go.
That's fair. I think my point with the paragraph still stands though, that this path has the highest bar of entry. I think the demand for this type of worker is way lower, even in the beltway.
+1 for Python.
I would also recommend learning Ruby, there are less tools written in it but Metasploit is and it's fairly important to have a good grasp of.
I would also recommend learning Ruby, there are less tools written in it but Metasploit is and it's fairly important to have a good grasp of.
+1 for Python. It dominates the security space in general.
Also good to know are C and Java/JVM.
Also good to know are C and Java/JVM.
I love a question with a simple right answer:
(Ruby OR Python) AND C.
You can skip C if you don't want to do low-level work (embedded, kernels, writing shellcode for memory corruption exploits). Only a small fraction of security people do this kind of work. You cannot skip (Ruby OR Python), even if you don't ever plan to do web work (which is a dumb plan anyways).
(Ruby OR Python) AND C.
You can skip C if you don't want to do low-level work (embedded, kernels, writing shellcode for memory corruption exploits). Only a small fraction of security people do this kind of work. You cannot skip (Ruby OR Python), even if you don't ever plan to do web work (which is a dumb plan anyways).
At Matasano was Ruby the primary scripting language?
Do you have any recommended resources for learning Ruby from a security point of view? Something like Blackhat Python (http://www.nostarch.com/blackhatpython).
Do you have any recommended resources for learning Ruby from a security point of view? Something like Blackhat Python (http://www.nostarch.com/blackhatpython).
What about Go? I haven't seen it mentioned in any of the answers.
Go looks very appealing and according to folks on #go-nuts it can be used for scripting. Also, it comes with a standard library that covers crypto, networking and most of what you might need.
I would think that being able to cross compile and deploy a single binary when doing pen testing would make Go a good candidate for the infosec field.
Go looks very appealing and according to folks on #go-nuts it can be used for scripting. Also, it comes with a standard library that covers crypto, networking and most of what you might need.
I would think that being able to cross compile and deploy a single binary when doing pen testing would make Go a good candidate for the infosec field.
Go is a great programming tool but it is not the first language you should learn if you're looking for a career in security.
Second this, but want to add:
You don't necessarily need to be able to sit down and bang out quality C, but learning some C is a great way to understand how software works at a lower level than you'll get from Python or Ruby. On the other hand you can apply that understanding to more quickly and correctly understand what higher level code is doing and what risks it is taking.
If you don't already have a good theoretical background, learn some C. Something like C++ or even Rust would work for this too, but those introduce a lot more language concepts that you don't really need.
You don't necessarily need to be able to sit down and bang out quality C, but learning some C is a great way to understand how software works at a lower level than you'll get from Python or Ruby. On the other hand you can apply that understanding to more quickly and correctly understand what higher level code is doing and what risks it is taking.
If you don't already have a good theoretical background, learn some C. Something like C++ or even Rust would work for this too, but those introduce a lot more language concepts that you don't really need.
I think C++ and Rust are actually a bad idea here. Learn C. Don't bother with C++ until you've got C down.
I mean, learn Rust if you want to write Rust code. But for the objective I'm addressing with C, you need C.
I mean, learn Rust if you want to write Rust code. But for the objective I'm addressing with C, you need C.
Agreed, in addition a lot (if not most) of the low level attack surface (drivers, kernels, web servers) are still written in C, it's still the lingua franca (with C++ somewhat second).
Would you do that by picking up a copy of K&R or would you have a more modern recommendation?
K&R is still a really good book that covers pretty much all of the language. Do note that it is very dated, and stylistically you should not try to emulate them. Looking at a modern C code base (I have heard redis is well structured) would be the best place to learn a modern style.
JavaScript/Node.js/modules are essentials now since Node is pretty popular. For example, many Bitcoin modules like Copay are written in JavaScript and not available in other programming languages.
Ruby or Python is more important than strong JavaScript, and everyone who knows Ruby or Python has at least weak JavaScript. If you specialize in JavaScript security, you need it, but you can say the same thing about Intercal.
I don't think you can fairly compare JavaScript with Intercal in this context. JS is very popular now and you can see a lot of job posts that give you a hint about the market size for security reviewing Node applications.
Additionally, Node modules are a fertile ground for bug searching.
Additionally, Node modules are a fertile ground for bug searching.
Sure. But the premise of the question is, what language (singular) should someone pick up to do "security for companies" (I read from that: appsec). I cheated by giving 2; formally, the right answer to this question was simply "Python OR Ruby".
JavaScript is the most deployed interpreter in the world, and therefore almost certainly handling the greatest amount of independent data in the world. So whether or not you think it's a bad joke, it's important.
I think I sent the wrong message with the Intercal comparison.
My point was that the logic that brings you to "you need Javascript if you specialize in Javascript security" works for any language, including Intercal.
It was not that Javascript is a language as dumb as Intercal.
If I had to make a list of 3 languages to know for security people, Javascript would probably be my #3 (Java might be #3, and Javascript #4; I'd have to think about it.)
BTW: Unlike a lot of people on this thread, assembly wouldn't be in my top 5. It is much, much more important that appsec people be able to fluently write C than it is that they be good assembly programmers. Even full-time reversers don't spend that much time reading assembly in bulk.
My point was that the logic that brings you to "you need Javascript if you specialize in Javascript security" works for any language, including Intercal.
It was not that Javascript is a language as dumb as Intercal.
If I had to make a list of 3 languages to know for security people, Javascript would probably be my #3 (Java might be #3, and Javascript #4; I'd have to think about it.)
BTW: Unlike a lot of people on this thread, assembly wouldn't be in my top 5. It is much, much more important that appsec people be able to fluently write C than it is that they be good assembly programmers. Even full-time reversers don't spend that much time reading assembly in bulk.
You very much have to be flexible. Most valuable would be C and assembly knowledge (and knowledge of the low level details of both is pretty much required).
As for tool writing, any high level language (perferably what your employer uses). For example, if MetaSploit is used knowledge of Perl/Ruby would be required.
Picking up multiple imperative languages is easy, though. Fortunately most languages in the field are imperative.
Depending on the software in question, knowledge of how virtual machines operate can also be useful.
As for tool writing, any high level language (perferably what your employer uses). For example, if MetaSploit is used knowledge of Perl/Ruby would be required.
Picking up multiple imperative languages is easy, though. Fortunately most languages in the field are imperative.
Depending on the software in question, knowledge of how virtual machines operate can also be useful.
First off, obviously there isn't really a clear black/white answer to this. Secondly even security is such a broad field that it really depends on your focus (a similar question could be what programming languages/technologies are the best for web development, where you'd get answers ranging from classic LAMP stack, to Node.js, python, RoR, Angular and many others, and it depends on whether you want to do front-end, back-end, both or whatever combination). So firstly I'd say it's important to pin-point what you are personally interested in; I'd say that if you want to be working on some "serious" exploits in widely used software, you are looking at C and Assembly, and C++. Obviously for web hacking, you'd be looking more at scripting languages, both in terms of their usages as the underlying technologies, as well as to automate those mundane repetitive tasks, so PHP, ASP, Perl, Python, Bash scripting etc. is something to look into.
But you should also be well versed in sys-admin tasks, things like maintenance, event logging, filesystems and permissions... And lastly there is networking and all the issues and things associated with it, tcp/ip stack, routing and so much more.
The thing is, working in security isn't really dependant on the programming languages you know, either what will matter is your specialization (if you have any), or the overall skillset that you can offer to the company (if you can secure a web application on a shared host, but don't do anything about file permissions and other settings on the server, either someone else needs to do it, or the security of the webapp is pretty useless); be aware that you will be (or should be) learning something all the time, again depending on your interests, and at the same time you have to stay on top of news in research and exploits, so in a way it's really tough but also very interesting.
The thing is, working in security isn't really dependant on the programming languages you know, either what will matter is your specialization (if you have any), or the overall skillset that you can offer to the company (if you can secure a web application on a shared host, but don't do anything about file permissions and other settings on the server, either someone else needs to do it, or the security of the webapp is pretty useless); be aware that you will be (or should be) learning something all the time, again depending on your interests, and at the same time you have to stay on top of news in research and exploits, so in a way it's really tough but also very interesting.
The E language (http://erights.org/) was designed to express smart contracts back before Bitcoin was invented -- really forward-looking and, to me, educational. You don't in the least need to know it for a career in the field, but it changed how I think about security.
http://erights.org/elib/capability/ode/index.html is probably the best quick intro.
http://erights.org/elib/capability/ode/index.html is probably the best quick intro.
FWIW, Cap'n Proto (https://capnproto.org) is a cross-language network protocol based on E's design (with direct help from E's creator, Mark Miller). So if you're interested in E-style capability-based security but want to use a more mainstream language, consider taking a look at Cap'n Proto.
(Also Sandstorm (https://sandstorm.io) is a server platform implementing this model. Disclosure: I am the lead developer of both of these projects.)
(Also Sandstorm (https://sandstorm.io) is a server platform implementing this model. Disclosure: I am the lead developer of both of these projects.)
Do 2 things in parallel.
Learn C, there's plenty of open source C code strictly related to security, from OpenSSL, to OpenSSH, to the Linux kernel.
Learn full stack web programming (SQL, a language, html+js). As for the language, PHP could be good as there's a lot of history of (in)security, but I definitely recommend learning a framework - I like yii (yes it is), but choose any. Studying a framework is useful to learn how much things could go wrong, if not done properly (SQL injection, XSS injection, ...).
Learn C, there's plenty of open source C code strictly related to security, from OpenSSL, to OpenSSH, to the Linux kernel.
Learn full stack web programming (SQL, a language, html+js). As for the language, PHP could be good as there's a lot of history of (in)security, but I definitely recommend learning a framework - I like yii (yes it is), but choose any. Studying a framework is useful to learn how much things could go wrong, if not done properly (SQL injection, XSS injection, ...).
There are a lot of great answers on here (Python/Ruby for general scripting, C/C++/ASM for reverse engineering, web stack technology for web application security, etc) -- but I wanted to focus on a slightly different approach.
I've run security teams for the last six years or so, and it's surprising to some people how little programming is often involved in penetration testing and application security assessments. If you're looking to do network and/or (web|mobile) application security, it's often unnecessary.
That said: learning how to do some scripting is always beneficial, and clearly understanding how code works is very important to understanding systems, networks, and applications. My advice, though, is that if you're trying to work in security it's probably better to learn the fundamentals of the area(s) of security that interest you, rather than focusing on a programming language or framework that you think will be relevant.
There are a lot of great resources out there, but shoot me an email (address in profile) if you'd like a little more info.
Good luck!
I've run security teams for the last six years or so, and it's surprising to some people how little programming is often involved in penetration testing and application security assessments. If you're looking to do network and/or (web|mobile) application security, it's often unnecessary.
That said: learning how to do some scripting is always beneficial, and clearly understanding how code works is very important to understanding systems, networks, and applications. My advice, though, is that if you're trying to work in security it's probably better to learn the fundamentals of the area(s) of security that interest you, rather than focusing on a programming language or framework that you think will be relevant.
There are a lot of great resources out there, but shoot me an email (address in profile) if you'd like a little more info.
Good luck!
Programming is a hard requirement for app pentesting.
Programming, but not software engineering. For example, it can be merely a nuisance if the tools you write leak lots of memory, acceptable to parse XML with a regular expression, and not a problem at all if programs run entirely within an environment you control aren't themselves secure.
OK, but it's not merely a nuisance if you can't understand why it's unsafe to parse XML with a regexp, and you might not grok the issue viscerally unless you're a good programmer.
I believe his point was that while you need to be able to do it, at least to a certain level, it's not where the majority of your day is going to be spent. I'm not in the field so I don't know true that is, however. That was just what I got from his post.
I think (a) that's a common belief among pentesters and (b) a pretty dangerous trap. You don't just want to be able to program; if you want to be good at this job, you want to be a really good programmer. There are a bunch of reasons why.
There are currently 17 threads in response to this question. None have taken the architectural angle, one that can be well introduced with the Rule of Least Power which states Use the least powerful language possible for a given problem. Prefer declarative languages over procedural. Now think for awhile about what that is actually saying...
Could it be that the heart of a secure system has little to do with process-oriented thought, and much to do with declarative policy?
In fact, in a well designed system, that should be the case. Unfortunately, there are bugs in all systems, so process-oriented thinking will always have a place. But in big picture terms - the 'heart' of a security stance - you really do need to be thinking in this way, particularly at design time, and generally also as an attacker.
Unfortunately, a declarative (policy-driven) architecture is essentially useless unless you ensure the system actually follows policy... for instance, by actually generating it largely from policy. This degree of rigor is rare in practice, but highly desirable in theory.
If you want to ensure your skills target big picture, are applicable to building things and not just tearing them to pieces (which in the security world often decays in to a range of puerile one-upmanship as visible at most prominent industry events), you could consider specializing in this area. In that case, you would do well to learn about declarative DSLs (domain-specific languages) and learn some of the more common ones. Then, practice generating things (documentation, functional code, application-level proxies, protocol test suites, policy compliance test suites) from those definitions... the generation could be done in any language, though using something simple with lots of libraries would be smart (possibly go, ruby, python, even perl or php).
Just thought it was worth contributing a different perspective here.
Could it be that the heart of a secure system has little to do with process-oriented thought, and much to do with declarative policy?
In fact, in a well designed system, that should be the case. Unfortunately, there are bugs in all systems, so process-oriented thinking will always have a place. But in big picture terms - the 'heart' of a security stance - you really do need to be thinking in this way, particularly at design time, and generally also as an attacker.
Unfortunately, a declarative (policy-driven) architecture is essentially useless unless you ensure the system actually follows policy... for instance, by actually generating it largely from policy. This degree of rigor is rare in practice, but highly desirable in theory.
If you want to ensure your skills target big picture, are applicable to building things and not just tearing them to pieces (which in the security world often decays in to a range of puerile one-upmanship as visible at most prominent industry events), you could consider specializing in this area. In that case, you would do well to learn about declarative DSLs (domain-specific languages) and learn some of the more common ones. Then, practice generating things (documentation, functional code, application-level proxies, protocol test suites, policy compliance test suites) from those definitions... the generation could be done in any language, though using something simple with lots of libraries would be smart (possibly go, ruby, python, even perl or php).
Just thought it was worth contributing a different perspective here.
Look into python and play around with scapy... look into Perl and play around with Metasploit... know how to implement your own Tor hidden-service keyserver and how to make your own site use an SSL/TLS cert... before you have completed all four of these tasks you will have a good idea of the landscape and will have learned a lot, possibly answering your own question.
Metasploit is Ruby. In 10 years of consulting with a progressively larger and larger team, I'm not sure I ever saw someone use scapy. It's not that scapy is bad, so much as that direct targeted low-level packet manipulation is kind of a 90s problem statement.
Gotcha, thanks for the clarification. So then, I suppose my recommendation of learning Metasploit and looking into Perl/CGI/PHP/javascript site security features are certainly separate/more than one thing. My aim was to suggest some broad "security programming" fields/projects that are easy to get started in or get quick results with and contain enough documentation and specialty uses that allow them to be drilled down into specifically if that part of the landscape interests OP. Also, doing cool things with scapy is fast and easy and learning to write your own scapy code seemed to teach me a lot about packet security very quickly. I was assuming that if one is an autodidact, the things I listed will keep you busy reading/learning related subject matter and introduce you to some cool things and familiarize yourself with what's out there while getting visible/fast results with a tool chain rather than just learning for learning's sake. There's a certain balance between thinking and doing; with excess of either it's easy to lose touch with reality/scope. This is why, when people want to "learn Linux" for example, I find out what they're interested in and point them toward some projects/packages... rather than pointing them to general Linux documentation which often has new users feeling like they're reading Greek without examples, or leads to eyeglaze.
Related: http://techcrunch.com/2015/05/02/and-c-plus-plus-too/
We fail to learn. Heartbleed. GHOST. The Android 4.3 KeyStore. Etcetera, etcetera, etcetera.
C was and is magnificent, in its way. But we cannot afford its gargantuan, gaping security blind spots any more. It’s long past time to retire and replace it with another language.
[...]
So please, low-level programmers of the world, I beseech you (while, to be clear, also respecting you immensely): for your next project, try Rust rather than C/C++. There is no longer any good reason for today’s software to be as insecure as it is. Those old warhorses have served us well, but today they are cavalry in an era of tanks. Let us put them out to pasture and move on.
(Personally I'm rather neutral on the issue (I don't work with low-level languages), I just think it's good food for thought.)
We fail to learn. Heartbleed. GHOST. The Android 4.3 KeyStore. Etcetera, etcetera, etcetera.
C was and is magnificent, in its way. But we cannot afford its gargantuan, gaping security blind spots any more. It’s long past time to retire and replace it with another language.
[...]
So please, low-level programmers of the world, I beseech you (while, to be clear, also respecting you immensely): for your next project, try Rust rather than C/C++. There is no longer any good reason for today’s software to be as insecure as it is. Those old warhorses have served us well, but today they are cavalry in an era of tanks. Let us put them out to pasture and move on.
(Personally I'm rather neutral on the issue (I don't work with low-level languages), I just think it's good food for thought.)
This is advice useful for architects and engineers, and would be preaching to the pen-testing choir.
It is necessary for the member of such a security company to think of the software that they learn is first a tool used to attack other software (Metasploit, Burp, hand-written tools such as WWMD, quick one-off, discardable code used during a test), and secondly to develop a deep understanding of how the software under test works.
And, as I and others have noted previously in this forum, not all of the dramatically-reported errors are due to the low-level nature of C. Some are glaring implementation-language independent protocol errors.
It is necessary for the member of such a security company to think of the software that they learn is first a tool used to attack other software (Metasploit, Burp, hand-written tools such as WWMD, quick one-off, discardable code used during a test), and secondly to develop a deep understanding of how the software under test works.
And, as I and others have noted previously in this forum, not all of the dramatically-reported errors are due to the low-level nature of C. Some are glaring implementation-language independent protocol errors.
There's also a language-portable state of mind.
http://phrack.org/issues/1/1.html
https://en.m.wikipedia.org/wiki/Fravia
http://phrack.org/issues/1/1.html
https://en.m.wikipedia.org/wiki/Fravia
I believe comments here that programming isn't a necessity aren't really correct. A strong programming knowledge to the point of expertise is what you should aspire towards in a security-related career.
Language is a hard question though, there are a lot of things to consider around what sector you want to focus on. The holy trinity seems to be Python, Ruby and C.
ASM is probably very overlooked in general, but also a lot harder to master. Good luck, hope you get to a point where you can take a few steps forward. This is going to be an enormous area of interest over the next few years (much more so than it already is) so enjoy the challenge and the money ;)
Language is a hard question though, there are a lot of things to consider around what sector you want to focus on. The holy trinity seems to be Python, Ruby and C.
ASM is probably very overlooked in general, but also a lot harder to master. Good luck, hope you get to a point where you can take a few steps forward. This is going to be an enormous area of interest over the next few years (much more so than it already is) so enjoy the challenge and the money ;)
Low-level stuff. C. Assembler. Firmware. Debuggers.
You're going to want to learn more than one, but for your first programming language I would suggest Python.
There are already a lot of people who suggested you a laundry list of langauges: yeah, you'll need to learn them all. However, that takes years. Don't fool yourself by thinking it doesn't. It will come with time.
There are already a lot of people who suggested you a laundry list of langauges: yeah, you'll need to learn them all. However, that takes years. Don't fool yourself by thinking it doesn't. It will come with time.
You can avoid C/C++/ASM if you're specialising in web application/mobile app security. However it's suggested you learn them anyway, given the domai8n of experience required for security roles.
This is going to be something of a rant, but roll with it.
This is a controversial opinion, but I don't believe someone should be a security engineer or a security consultant until they are a provably competent software developer.
This harkens back to the analogy of writing and editing - how can you expect to perform competent source code review from a security perspective without having a deep understanding of programming? Even if you do not know a specific language you're reviewing (ideally you should, though), you can at least generalize your understanding to look for common patterns of insecure coding.
The reason why I stress this so emphatically is because, despite the fact that you are asking which programming languages to learn, my experience with the security industry is that most people just don't have much real programming experience, which is absurd.
There are many firms where they will bill out their consultants at $2000+ per day and their consultants couldn't build a simple Twitter clone if they were handed a complete spec.
I would much rather someone who can sit down and write a compiler and who has no security experience whatsoever than someone who knows all the payloads for XSS and how to find them manually. One of these people understands software engineering as a discipline and where it goes wrong, and the other is basically learning different "routes" without truly understanding everything under the hood. I can teach the person who writes compilers to find serious memory corruption vulnerabilities in a week. I can't teach someone who has never programmed to find subtle mass assignment flaws in Ruby/Rails.
This is not a straw-man dichotomy. Like 'tptacek said, it is absolutely necessary for you to have a programming background if you want to work in AppSec. And God help you if you try to work on security in firmware or embedded systems and don't have this background.
My personal opinion is that all security engineers should be senior software engineers. There is a good quote by Ryan McGeehan (former Director of Security at Facebook, then Coinbase, now Hackerone) where he explains that the most competent security engineers start out by fully mastering a particular discipline. After they hit that point, finding vulnerabilities becomes extremely easy. You don't need to memorize different payloads or routes or rote methods of testing. When you have written a lot of C you will understand a buffer overflow in a half hour (enough to really be dangerous, anyway).
Working in security without a lot of experience programming is like trying to ski a black diamond without having mastered all the fundamentals. Do not do it. It is entirely too fashionable in the industry to hire people who don't know what they're doing, please do not add to this.
Now that my rant is over - you should learn Python and C. Ruby and Lua are also good; most people you'll find in the industry will be doing scripting in Python. You should know C for its rich history and deep connection with the information security industry, and also because most of the interesting vulnerabilities will be found in software projects written in C.
Source: A few years of security consulting, and now working as a security engineer in FinTech.
This is a controversial opinion, but I don't believe someone should be a security engineer or a security consultant until they are a provably competent software developer.
This harkens back to the analogy of writing and editing - how can you expect to perform competent source code review from a security perspective without having a deep understanding of programming? Even if you do not know a specific language you're reviewing (ideally you should, though), you can at least generalize your understanding to look for common patterns of insecure coding.
The reason why I stress this so emphatically is because, despite the fact that you are asking which programming languages to learn, my experience with the security industry is that most people just don't have much real programming experience, which is absurd.
There are many firms where they will bill out their consultants at $2000+ per day and their consultants couldn't build a simple Twitter clone if they were handed a complete spec.
I would much rather someone who can sit down and write a compiler and who has no security experience whatsoever than someone who knows all the payloads for XSS and how to find them manually. One of these people understands software engineering as a discipline and where it goes wrong, and the other is basically learning different "routes" without truly understanding everything under the hood. I can teach the person who writes compilers to find serious memory corruption vulnerabilities in a week. I can't teach someone who has never programmed to find subtle mass assignment flaws in Ruby/Rails.
This is not a straw-man dichotomy. Like 'tptacek said, it is absolutely necessary for you to have a programming background if you want to work in AppSec. And God help you if you try to work on security in firmware or embedded systems and don't have this background.
My personal opinion is that all security engineers should be senior software engineers. There is a good quote by Ryan McGeehan (former Director of Security at Facebook, then Coinbase, now Hackerone) where he explains that the most competent security engineers start out by fully mastering a particular discipline. After they hit that point, finding vulnerabilities becomes extremely easy. You don't need to memorize different payloads or routes or rote methods of testing. When you have written a lot of C you will understand a buffer overflow in a half hour (enough to really be dangerous, anyway).
Working in security without a lot of experience programming is like trying to ski a black diamond without having mastered all the fundamentals. Do not do it. It is entirely too fashionable in the industry to hire people who don't know what they're doing, please do not add to this.
Now that my rant is over - you should learn Python and C. Ruby and Lua are also good; most people you'll find in the industry will be doing scripting in Python. You should know C for its rich history and deep connection with the information security industry, and also because most of the interesting vulnerabilities will be found in software projects written in C.
Source: A few years of security consulting, and now working as a security engineer in FinTech.
I don't think this is controversial at all. It's completely agreeable.
Perhaps when you get more than "a few years" of experience, you'll notice that there's significantly more to the field of information security than application security. In many of those other areas, programming is at best peripheral to competence in the job.
Source: 30 years of security consulting and entrepreneurship, without being a developer.
Source: 30 years of security consulting and entrepreneurship, without being a developer.
It is good to learn python/c/c++/java.These programming languages will help you.
what kind of security? for instance web exploits can be written in any language even in bash scripts,. Your question is way to vague to give an accurate and pertinent answer.
It's more about how you use it than the language itself.
Thanks so much for all the advice so far!
Python can be very useful
its helpful to know the clients language of choice
i would say 75% of the time: asm/c/c++/sql are req languages. python may be as well, lots of exploits are written in python b/c its fast to write for...
if you dont got that ur gonna need or bonus to have: knowledge of exploit methods for bash/win/php/ruby/sql and other common languages
just my take on it, cheers
i would say 75% of the time: asm/c/c++/sql are req languages. python may be as well, lots of exploits are written in python b/c its fast to write for...
if you dont got that ur gonna need or bonus to have: knowledge of exploit methods for bash/win/php/ruby/sql and other common languages
just my take on it, cheers
I assume it would be something like C++, but I don't know.
On another note, how many programming languages (and what programming languages) do you think someone would need to know to have a successful career in that field?