The reason that you hear a lot about errors using C is because it is a popular language, used in many important systems and libraries where some easy-to-compute errors can be converted into vulnerabilities (access to vector out of bounds, "dangling pointers", etc.).
That said, a vulnerability is anything an adversary can use against your system, which is extremely broad and can occur with any system regardless of which language is used in its implementation.
A simple example we can have are code injection vulnerabilities, such as SQL injection. For example, suppose I have a web page where the user types the name of a country and the system responds with the number of goals that country scored in the world cup. If my data is in a relational database I will have to prepare a question for the bank similar to the following:
pergunta = "SELECT gols FROM tabela_copa WHERE pais='Brasil';"
gols = bandoDeDados.executar(pergunta)
The naive way to pass the country chosen by the user is to use concatenation or interpolation of strings:
pais = entrada_do_usuario()
pergunta = "SELECT gols FROM tabela_copa WHERE pais='" + pais + "';"
gols = bandoDeDados.executar(pergunta)
Now, what happens if the user enters the following "country" in the search field?
'; DROP TABLE tabela_copa
The generated command will be
SELECT gols FROM tabela_copa WHERE pais='';
DROP TABLE tabela_copa;
And we'll delete all our data from the bank. Basically we gave a loophole for the user to execute SQL in our database on our behalf and the database, which trusts us, executed the commands blindly.
The execution of SQL code is not as direct a vulnerability as a buffer overflow defect, but it is still a form of privilege escalation and remote code execution. Similar problems with code injection are also very common in other contexts:
- Incorrect handling of user data in HTML pages can lead to cross site scripting (XSS) vulnerabilities.
- Servers evaluating user code data as code. For example, in PHP this can occur in regular expressions with the / e
-
Phreaking , a technique involving a series of precise whistles that early hackers used to speak for free on the payphone.
Well, someone can call now and say that these bugs are the fault of the programmer and not the language. But it's true? I've tired of hearing people using that same argument to defend C ("if you never accessed vectors out of bounds, you would not have to worry about overflow") and it's entirely possible that the language or system will protect you from these vulnerabilities. For example, if you used a separate data type for HTML and user-generated strings you would not be able to treat user values as HTML. The only way to pass a string to the HTML document is to first pass it through the escape function. Similarly, you can avoid SQL injection if the data type used to describe SQL commands does not support the concatenation operation.
Regarding the vulnerabilities of Java or Flash in the browser, the main problem is that these systems are large and will inevitably contain bugs, which will come to the fore when those systems have to deal with hostile entries from malicious users on the internet. For example, some versions of the flash plugin (implemented in C ++) were given a stack overflow when trying to read certain corrupted swf files, and some versions of the JVM allowed malicious applets to scale their privileges and escape the secure sandbox.
