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?
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
Also good to know are C and Java/JVM.
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.
(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.
(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).
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 mean, learn Rust if you want to write Rust code. But for the objective I'm addressing with C, you need C.
Additionally, Node modules are a fertile ground for bug searching.
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.
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.
Do you have any recommended resources for learning Ruby from a security point of view? Something like Blackhat Python (http://www.nostarch.com/blackhatpython).
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.
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.
http://erights.org/elib/capability/ode/index.html is probably the best quick intro.
(Also Sandstorm (https://sandstorm.io) is a server platform implementing this model. Disclosure: I am the lead developer of both of these projects.)
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, ...).
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!
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.
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.)
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.
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 ;)
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.
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.
Source: 30 years of security consulting and entrepreneurship, without being a developer.
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