Realizing and researching information about most dangerous programming language and compiling the information about it could prove challenging and confusing sometimes, especially when you have no prior knowledge of it. Finding the right information on it also might not be quite as straightforward as you think it should be. Not to worry though as the article below puts you out of the stress of fretting about most dangerous programming language.

Read on to find out accurate ans precise information about most dangerous programming language as well as what is the safest programming language, what is the worst programming language, what is the most hated programming language, , what is dangerous software called, the most dangerous code in the world, least secure programming languages In related articles on collegelearners.

EDITION:

These are the most insecure programming languages

WhiteSource review of programming language security errors reveal which languages have the most security holes. The winner? C. But that’s only the start of the story.

By Steven J. Vaughan-Nichols for Linux and Open Source | March 25, 2019 — 20:20 GMT (13:20 PDT) | Topic: Security

SECURITY

From top to bottom, technology is riddled with security errors. At the lowest level, we have hardware errors such as Intel’s Meltdown and Spectre bugs. Just above those, we have programming language security holes, and boy, do we have a lot of those!

WhiteSource, an open-source security company, recently did a study of open source security vulnerabilities in the seven most widely used languages over the past decade. To find the bugs, the company used its language security database. This contains data on open-source vulnerabilities from multiple sources such as the National Vulnerability Database (NVD), security advisories, GitHub issue trackers, and open-source projects issue trackers.

Here’s what the company found: The most insecure languages are C, Java, JavaScript, Python, Ruby, PHP, and C++. There are no surprises.

There’s also no surprise as to which language had the most security bugs. That’s C, by a wide margin. Nearly 50 percent of all reported vulnerabilities were in C.

As Kees “Case” Cook, Google Linux kernel security engineer, said recently: “C is a fancy assembler. It’s almost machine code.” In addition, “C comes with some worrisome baggage, undefined behaviors, and other weaknesses that lead to security flaws and vulnerable infrastructure.”

But, WhiteSource argued:

This is not to say that C is less secure than the other languages. The high number of open source vulnerabilities in C can be explained by several factors. For starters, C has been in use for longer than any of the other languages we researched and has the highest volume of written code. It is also one of the languages behind major infrastructure like OpenSSL and the Linux kernel. This winning combination of volume and centrality explains the high number of known open-source vulnerabilities in C.

They have a point. But having programmed and fought with C for decades now, I have found it really is way too easy to make terrible security blunders in C. For example, C contains a great deal of undefined behavior, which leaves all kinds of nasty possibilities open.

C++, however, has the “honor” of having the most high-severity vulnerabilities in the past five years. Buffer errors, which have long plagued C, are also now being discovered often in C++.

Language Security Bugs — The numbers don’t tell the full story when it comes to which language is the least, or most, secure. (Image: WhiteSource)

That said, JavaScript, perhaps the most popular language, is also the only one that saw a “continuous rise in the number of vulnerabilities in the past 10 years.”

Before making too much fun of JavaScript, those results, WhiteSource points out, are misleading. Most of JavaScript’s Common Weakness Enumeration (CWE)s are Path Traversal and crypto security holes from JavaScript packages, which are barely used, maintained, or supported.

So, why are they — and other language problems — showing up? New automated programs, such as Source Code Analysis Tools, are spotting vulnerabilities, which otherwise would have been overlooked.

The one language which has been showing well on security holes, is — drumroll, please — Python. Yes, good old — often made fun of — Python.

Nearly all languages share some CWEs. Two CWEs are found in 70 percent of the most common languages: Cross-Site-Scripting (XSS), aka CWE-79 and Input Validation, otherwise known as CWE-20.

Other CWEs that show up a lot are: Information Leak/ Disclosure (CWE-200), Path Traversal (CWE-22), and CWE-264 Permissions, Privileges, and Access Control. The last is being displaced recently with its more specific, close relative — Improper Access Control (CWE-284).

But is C really the worst and Python the best? WhiteSource thinks that’s much too simple a conclusion: “While the game of ‘my programming language is safer than yours’ is certainly a fun way to pass time … finding the answer will probably not help you create the most innovative or secure software out there.”

No, instead you should spend your time “staying on top of known open-source vulnerabilities and understanding the strong and weak points in the programming languages you and your team are using.”

In the end, security is not about the languages, but how you use them.Technology we hate with a passion SEE FULL GALLERY

1 – 5 of 28NEXT

NEWSLETTERS

SEEALL

Slashdot

SubmitSearch Slashdot

Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!https://fceea7d53a139ae27b0cc9f661c906bc.safeframe.googlesyndication.com/safeframe/1-0-38/html/container.html https://fceea7d53a139ae27b0cc9f661c906bc.safeframe.googlesyndication.com/safeframe/1-0-38/html/container.htmlSlashdot Apparel is back! SHOP NOW! | Do you develop on GitHub? You can keep using GitHub but automatically sync your GitHub releases to SourceForge quickly and easily with this tool and take advantage of SourceForge’s massive reach. Check out all of SourceForge’s improvements. | Follow Slashdot on LinkedIn×

Which Programming Language Has The Most Security Vulnerabilities? (techrepublic.com)330

Posted by EditorDavid on Sunday March 24, 2019 @11:39PM from the battle-of-the-bugs dept.A new report from the open source security company WhiteSource asks the question, “Is one programming language more secure than the rest?”

An anonymous reader quotes TechRepublic:To answer this question, the report compiled information from WhiteSource’s database, which aggregates information on open source vulnerabilities from sources including the National Vulnerability Database, security advisories, GitHub issue trackers, and popular open source projects issue trackers. Researchers focused in on open source security vulnerabilities in the seven most widely-used languages of the past 10 years to learn which are most secure, and which vulnerability types are most common in each…

The most common vulnerabilities across most of these languages are Cross-SiteScripting (XSS); Input Validation; Permissions, Privileges, and Access Control; and Information Leak / Disclosure, according to the report.
Across the seven most widely-used programming languages, here’s how the vulnerabilities were distributed:

C (47%)
PHP (17%)
Java (11%)
JavaScript (10%)
Python (5%)
C++ (5%)
Ruby (4%)

But the results are full of disclaimers — for example, that C tops the list because it’s the oldest language with “the highest volume of written code” and “is also one of the languages behind major infrastructure like Open SSL and the Linux kernel.”

The report also notes a “substantial rise” across all languages for known open source security vulnerabilities over the last two years, attributing this to more awareness about vulnerable components — thanks to more research, automated security tools, and “the growing investment in bug bounty programs” — as well as the increasing popularity of open source software. And it also reports a drop in the percentage of critical vulnerabilities for most languages — except JavaScript and PHP.

The report then concludes that “the Winner Of Most Secure Programming Language is…no one and everyone…! It is not about the language itself that makes it any more or less secure, but how you use it. If you are mitigating your vulnerabilities throughout the software development lifecycle with the proper management approach, then you are far more likely to stay secure.”

Coincidentally, WhiteSource sells software which monitors open source components throughout the software development lifecycle to provide alerts about security (and licensing) issues.

←

→

Can We Build Ethics Into Automated Decision-Making?

Is PHP Still a Worthwhile Language To Learn?

First-of-Its-Kind US Nuclear Waste Dump Marks 20 Years Sponsored Content ?

Human Resources Software | Compare of the Most Popular HR Software

Posted by Slashdot

Top Human Resources (HR) Software Software of 2019
Looking for Human Resources Software? Find the best�HR Software for your business here. Compare product reviews and features of the leading�HR Software providers on SourceForge. Feel free to leave a review to help other shoppers!
Are you looking for HR software for your Business?Compare Nowhttps://fceea7d53a139ae27b0cc9f661c906bc.safeframe.googlesyndication.com/safeframe/1-0-38/html/container.htmlSponsored LinksFrom The Web The Simple Trick To Unlock Netflix RestrictionsTheTopFiveVPNAustralian Skilled Immigration – Start a New Life in Australia in 2021!Australia Immigration ProfessionalsDo You Speak English? Work a USA job from home in NigeriaWork from Home | Search AdsCost Of MBA Degree in Asaba Might Surprise You!Shortest MBAby Taboolahttps://fceea7d53a139ae27b0cc9f661c906bc.safeframe.googlesyndication.com/safeframe/1-0-38/html/container.html

Which Programming Language Has The Most Security Vulnerabilities?

Archived Discussion Load All Comments24 Full76 Abbreviated0 Hidden/SeaSearch 330 Comments Log In/Create an AccountComments Filter:

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

›Not the programming language (Score:4, Insightful)by hcs_$reboot( 1536101 ) on Sunday March 24, 2019 @11:42PM (#58328490)but the programmer that uses it.Share
- Re:Not the programming language (Score:5, Insightful)by hcs_$reboot( 1536101 ) on Sunday March 24, 2019 @11:45PM (#58328508)But to be fair. some languages are more prone to security holes (like PHP, especially the older versions).ParentShare
  - Re:It is only really the default configuration of older PHP versions that make it so much more practically insecure. In reality, JavaScript should be higher up on this list, because some of it’s innate behaviors are so badly designed they cause vulnerabilities that can’t be mitigated in any way other than simply not using it.
    - Re:Not the programming language (Score:5, Interesting)by ShanghaiBill( 739463 ) on Monday March 25, 2019 @02:38AM (#58329064)PHP has more than a dozen different ways to connect to a database. PHP has a long history of glomming on new APIs, but never deprecating the old, even when shockingly insecure. This is especially bad for PHP because most of PHP’s user base are low IQ WordPress extension hackers who are not qualified to be making security decisions on their own.ParentShare
      - Re:Not the programming language (Score:4, Interesting)by AmiMoJo ( 196126 ) on Monday March 25, 2019 @04:52AM (#58329370) Homepage JournalThe same is true of C programmers though, far too many of them don’t understand the language and just hack stuff together to fulfil the contractual obligations and then disappear.Contract work is a particular problems. There was a study recently, sorry I lost the link, where they put out contracts for a basic login page. Most of the developers didn’t bother storing the password securely at first, then when asked managed to botch doing it. Contract work encourages minimum effort and throwing unsuitable libraries at problems, and often the person checking for completion doesn’t understand the security issues.Parent Share
        
        Re:Not the programming language (Score:5, Insightful)by ctilsie242 ( 4841247 ) on Monday March 25, 2019 @08:22AM (#58329948)I would say that everyone is right here. C, it is easy to make mistakes which cannot happen in Java or Python, like not watching where pointers are going, array out of bounds issues, and other stuff.However, part of it is modern coding in general. The last several “Agile” places I worked at were in permanent sprints, and the job of the developers is to get a feature that marketing already sold to the customer into the product. It doesn’t matter if it doesn’t work, or is horrifically insecure. It is about making those deliverables in time. When one was made, marketing had two more waiting to be done, so it never ceased.In most places, one can easily wind up having their job outsourced/offshored if they don’t make deliverables. On the other hand, something horrifically insecure that causes every customer to have a backdoor to the world, the developer is insulated from that, through many layers of corporate bureaucracy, so even if there are lawsuits, the developer would likely feel no consequences.tl;dr, blame the programmer, not the tools. However, some languages require more thought to program safely/securely than others.Parent Share
        
        Re:I wrote a kernel module not long ago… in C. I was extremely diligent to make the code as clean as possible and to make the memory and error management as perfect as possible. I even added as many checks as I could. I wrote massive amounts of unit and integration tests. I configured multiple static code analysis systems to keep the code as pristine as possible… you shouldn’t even be able to look at the code without causing some warning to be generated.
        
        Then we got to procfs which is a bleeding disaster.
        
        No
      - Re: Not the programming languageIts like the what dogs bite the most people scenario, yes Labradors are way up on the list, but only because theres so many of them compared to other breeds.
    - Re:So the fact that PHP can introduce weird bugs due to surprising behavior of even basic operations is irrelevant for security now?And an example of that would be…what exactly?
      - Re: HebrewThis shit is really depressingly stupid. You might actually accomplish your goal of getting me to stop coming to slashdot entirely.
  - Re:No. The only thing PHP does is to make it easier for bad coders to create really simple to exploit vulnerabilities. Anybody competent will write code just as secure. It may take them longer because PHP is a really, really bad design that no good coders would use given a choice. (If you think different, then you are not a good coder. Sorry. It is completely clear and you are deluding yourself. PHP ignore fundamental principles of good engineering in many places.)
    - Re:Not the programming language (Score:5, Interesting)by hcs_$reboot( 1536101 ) on Monday March 25, 2019 @01:55AM (#58328954)Of course the programmer creates security holes by how they use the language. But in PHP (more the case in older versions) some “features” gives a sense of security while they actually don’t. ‘addslashes()’ vs ‘mysql_real_escape_…’ for instance ; ‘strpos’ that returns ‘false’ if not found (instead of -1) so in a ‘if’ the programmer might misses a position at 0… Local functions are actually not local… etc… etc… All of that is Ok when you’re used to the language, but they’re just counter-intuitive traps that even a good programmer may fall into at the beginning.ParentShare
      - Re:Not the programming language (Score:5, Insightful)by gweihir ( 88907 ) on Monday March 25, 2019 @02:52AM (#58329104)I agree. PHP has traps by surprising behavior. One of the corner-stones of secure coding is the Principle of Least Surprise and PHP violates it repeatedly. Still a good coder will find these and just not trust the language anymore and be extra careful. This makes coding slow and not fun and expensive, but it can be done. An average or worse coder (the majority of them) will just fall in the traps and create insecure code. However, an average or worse coder will still screw up more than acceptable in a well-designed language.Parent Share
        
        Re:So does Python; hasn’t hurt either of them popularity-wise.
        Re:Python is not nearly in the same class here.
        Re:Not the programming language (Score:5, Informative)by gweihir ( 88907 ) on Monday March 25, 2019 @06:08AM (#58329580)I have done stuff in both and I do not agree in the least. PHP is a dangerous mess. You need to understand its specific defects to code safely in it. Python is pretty well-designed but _not_ a language for beginners in OO concepts, functional coding, etc. It requires experience with the general concepts used, but not with the specific implementation in Python. As such, it does not violate the principle of least surprise.Parent Share
        Re:I really hope you are joking that an assignment operation can cause a loss of data because if you are, please close your editor, walk away from your computer and look for a new profession because you should NOT be writing code.
        Re:Not the programming language (Score:5, Informative)by gweihir ( 88907 ) on Monday March 25, 2019 @09:59AM (#58330346)Scope in Python is complex. However, it is absolutely nothing that will surprise anybody competent. Because if you have a variable twice, with different scope, anybody competent will read up how scope works before. Also, “accidentally” reversing an assignment is a code bug and nobody with the least bit of understanding would ever blame the language for the effects.Parent Share
        Re:The person is referring to the scoping rules in python not being like the scoping rules in C/Java/etc. It is only really a ‘gotchya’ if you have learned one set of rules and transition over to Python without learning it uses another one. But basically, in Python such a mistake can affect data that someone from a C/Java/etc background would consider out of scope but isn’t.
        
        This is the general problem with these ‘unexpected behavior’ type discussions, they make sense or not depending on what other languages
        Re:Not the programming language (Score:4, Interesting)by swillden ( 191260 ) <shawn-ds@willden.org> on Monday March 25, 2019 @02:14PM (#58331884) JournalIn what language does writing “x = y” when you meant “y = x” not lose the value of x, which you intended to keep?Everything *MUST* *BE* unit-tested for type-correctnessWhile I prefer static typechecking, I respect the Python view that everything must be tested for correctness anyway, and that static typechecking just lulls the programmer into thinking that less testing needs to be done than is really the case.I will say that the worst, most opaque code I have ever encountered was written in Python, but I blame the programmer who wrote it, not the language for making it possible. Bizarre, incomprehensible, even misleading code is possible in any language, only the techniques differ.(The code I mention created a set of pure interfaces, then instantiated them and called their methods… and they worked! There was machinery that intercepted the instantiations and chose appropriate concrete types. Essentially it was a particularly opaque dependency injection framework. Think Guice, if you’re familiar with that, but with absolutely nothing in the code to indicate that dependency injection was happening.)Parent Share
        Re: Not the programming languageExamples?
        
        Re:I agree that this is a strong component in this mess.
    - Re:Not the programming language (Score:4)by Sique( 173459 ) on Monday March 25, 2019 @02:57AM (#58329120) HomepageIf you think that a good coder has to avoid certain languages, I have news to you: Ed Post (1982) [mit.edu] begs to differ.[,,,] the determined Real Programmer can write FORTRAN programs in any language.Ironically, this is an article why Real Programmers avoid Pascal.ParentShare
      - Re:What is the relation between your statement and what I wrote? Can you explain?
        
        Re:The idea that you disqualify as a coder if you code in certain languages. I’ll code in any language you throw at me if necessary. Sometimes, you have to do with the things at hand. Life is not a picnic.
    - Re:No true Scotsman would write insecure PHP code, right?
      - Re:You need to read up on how that fallacy works. Here is a hint: It requires a disconnect between the group-characteristic and the excluded examples. That disconnect is missing in my statement and hence the fallacy does not apply.
        
        Re:Nah, that fallacy doesn’t work that way. Besides, your statement, is, in fact, even worse, because it is also an example of circular logic.
  - Re:Most script languages are written in C.C is a good language for focused functionality where performance or detailed control is important like hardware drivers, but when you look at bread&butter code then there are actually better languages. The problem is that not all those languages are as portable as C to other environments or even between versions due to breaking backward compatibility.A C program written in K&R style can still be compiled even if the compiler may moan quite a bit about obsolete
    - Re:C used to be a good language for focused functionality where performance or detailed control is important, but that was long ago. Modern computers are very different to a PDP11, yet C more or less forces them into these constraints.
      - Re:https://queue.acm.org/detail.c… [acm.org]This explains it better than I ever could.
  - Re:I wonder then, if you took a random group of programmers, and gave them all a fixed amount of time to produce some sort of output in different languages, how many of them would (a) finish in time and (b) produce a secure output.My point is, much like yours, that some languages make it easy to be reasonably secure, others make it quite hard. Any language can produce secure code, but given it’s somewhere on the easy/hard spectrum, which one is the quickest to produce a secure output? Additionally, which one p
- Re:And that is the only aspect that matters. Anything else is a red herring or a minor issue. But too many people that think they are competent to voice their opinion on the matter cannot see that and hence the mess continues. Will probably take a few really large disasters to change anything here.
- Re:Exactly. C is the hard parts. Lots of mistakes are made.It opens whole markets.
- Re:Most likely the libraries they use.E.g. below one is nitpicking about PHP and he obviously does not know that PHP got greatly improved during the last ten years.OTOH there plenty of mistakes you can make by simply configuring your server wrong, then the language does not really matter …
- Re:We can fix that: Simply replace humanity with a different humanity that is capable of writing secure C code.Or we can use memory-safe languages where possible.I vote for the latter.
- Re:Also to note what the programming language is used for.
  If I am tasked to program an “Enterprise” Class application I will be using C,Java,C++ (And Javascript if there is a web front end) because these are the languages the big Execs expect to be codded in, There is still a wide hiring base for expansion, Other “Enterprise” Applications are codded in these languages, and these languages have support from many big players. Despite the fact that I normally shutter when I hear “Enterprise” class, because it i
  - Re: Not the programming language (Score:5, Insightful)by hcs_$reboot( 1536101 ) on Sunday March 24, 2019 @11:56PM (#58328562)You can juge a programmer by the code they provide, whatever the language.ParentShare
    - Re: Not the programming languageGood programmers write good code in every language. A bad programmer writes bad code in all of them.
      - Re: Not the programming language (Score:5, Insightful)by Drethon ( 1445051 ) on Monday March 25, 2019 @08:25AM (#58329962)Good programmers write good code in every language. A bad programmer writes bad code in all of them.Good programmers may not write good code in a language they don’t understand yet. A great C# programmer could easily end up writing code with major memory holes in C because they don’t understand the differences in memory management. A great Java programmer could end up making utter trash with sql because of the different ways of thinking about the languages.Parent Share
        
        Re:I agree with your point, but I don’t think you could even get any real work done in C without understanding part of the memory management. In the case of your SQL example, that’s more likely to have massive performance problems than a security vulnerability.I don’t think you need experts, but you do need people who are willing to look at best practices documents when working in a new language. That are books on writing secure C and Java code as well as various papers and sites with content. There’s also p
        
        Re:As somebody who specifically works with undergraduate students with a Java background, the first few C++ programs I get from (almost) every new intern while training them is full of “Foo* bar = new Foo();”, without the accompanying deletes. The way that happens is pretty clear: they’re used to instantiating instances with new, they get a compiler error that indicates they should have an asterix next to they type when they do that, so they add an asterix.Granted, the process with C would be a bit different b
      - Re:No they don’t. This is a myth programmers tell themselves.
        There are safe languages and there are unsafe languages.
        Given same time, the performance of similar programmers (good or bad) will vary widely across them.
        This is the entire point of programming language research.A good programmer writing Haskell, Ada or Rust (languages that prioritize safety) code will invariably make fewer errors than he will in C (minimal safety features) – given same programming goals and time.
        
        Re:Why on earth would you compare an expert vs. beginner when comparing tools?That’s like saying, our car is just as safe as the rest, but only when driven by Grand Prix winners.Do you understand comparison studies? You control for every other variable.
        I specifically wrote: “the performance of *similar* programmers”.
        You compare Bill Atkinson like programmer performance using both safe and unsafe tools. *Separately*, you then compare mediocre programmers.
        Also note that I also wrote “Given same time”.
  - - Re:C is an assembly macro language.
      - Re:But it is though.Anyone proficient in assembly and C can “see” the assembly that the C code will make, as they write the C code. This is not true in C++ or FORTRAN or the others.
        
        Re:This is not true in C++ or FORTRAN or the others.
        Yes, it is.
        On the other hand, modern compilers make so much behind the scene that you *on modern hardware* hardly can say what is going on without actually looking at the assembly code. (Register renaming, operation reordering, parallel speculative execution etc.)
        
        Re:Yeah… with C, today you really only get the illusion of seeing what the assembly would look like on a toy processor from 30 years ago.
        
        Re:Anyone proficient in assembly and C can “see” the assembly that the C code will make, as they write the C code. What a load of bullshit. Between multiple targets, compilers, and the dozens and dozens of flags and options which affect compiler output, anybody who knows what they’re talking about will say never assume anything unless you look at the assembly yourself. This is why sites like https://godbolt.org/ [godbolt.org] exist. You have to be in an incredibly small, tightly controlled, limited scope environment to reall
        
        Re:That hasn’t been true for optimized C code for over a decade now. The compiler will surprise you in amazing ways in order to eek a cycle out of out-of-order instruction processing. And C++ isn’t particularly mysterious once you get the hang of it.
Easy way to rank (Score:3)by LynnwoodRooster( 966895 ) on Sunday March 24, 2019 @11:44PM (#58328506) JournalThe more flexible the language, the more ways you can screw up and allow a security hole.Share
- Re:In this case Perl should be in the top 3.
- Re:Case in point: PERL.
  - Re:Or a language that doesn’t allow uncontrolled system access. That’s probably why Javascript does not top the list here.
  - Re:That’s a good way of putting it.Secure languages are definitely not nice languages for the programmers … they want freedom (pointers) and convenience (type inference) but giving it to them runs counter to security.
    - Re:First, he has to sign the 732 page ethics and Code of Conduct agreement…
      - Re:Females don’t need to sign it; nothing they do is wrong.
Kinda silly conclusion. (Score:4, Insightful)by thoth_amon( 560574 ) on Sunday March 24, 2019 @11:54PM (#58328548)Language design unquestionably makes certain programming errors more difficult or even impossible. This is not mere tilting at windmills: many of the classes of errors that are removed are extremely important and damaging ones. Other language features can force programmers to think through their designs more and/or make their code more clear and expressive. Some language designs can even limit and constrain the possible logic errors that a program can commit.Obviously, naturally, a better programmer will write more secure programs, in any language. But that’s not a very interesting question. The interesting question is whether two equally skilled, equally disciplined programmers will write equally secure programs when one of them is allowed by the language to do anything, and the other has many guardrails in place to prevent errors.Share
- Re:No. You cannot force people to think. The avoidance of thinking is one of the most refined skills in the human race. No tools can help here. This false belief is at the root of the current mess, were more and more effort is poured into languages with no real effect. Of course, the motivation behind this is to avoid addressing the continued management failure in both hiring cheap, incompetent coders and in making tech decisions.
  - Re:Show me an actual, scientifically sound study first that backs your claim. Because your reference does not do that. Instead if regurgitates the ages-old fallacy that because specific vulnerabilities are removed from the possible things you can code, the same coders will write better code. That is not the case and nobody has ever been able to prove otherwise.
    - Re:So you can’t demonstrate anything to support your claim. You’ve had every chance and every opportunity and yet you show nothing. Your claims are plainly baseless and a waste of everyone’s time.
      - Re:Indeed. Nice to see that there are people that can think here. Even if you are an AC.
    - Re:Bottom line you learn coding by coding a lot. Making mistakes realizing it, reflecting about it and improving yourself.You can not simply “teach” how not to make mistakes. Sure, you can teach concepts, problem cases, defensive strategies, tests etc. But bottom line the only way to learn is to make mistakes and learn from them.
    - Re:Maybe try reading it. I know reading is hard for you but do try.
- - Re:So, I am reading that you haven’t done any embedded programming since they invented C. You can do most of than in C, and use the inline assembler where necessary.C lets you write assembler more easily.
- - Re:Yes, much easier to fuck up in C.But sometimes you need the no-training-wheels approach from C. The last time I’ve used it was for a simulation which would have taken at least 4 times the memory using Java or C++. When you’re using 80% of your available memory, 4x isn’t possible.
AMD64 assembly (Score:3)by reanjr( 588767 ) on Sunday March 24, 2019 @11:55PM (#58328556) HomepageThe vast majority of security vulnerabilities in the wild are running AMD64 assembly. It’s by far the least secure programming language.Share
- Re:Especially if run on the inferior “Intel” implementation.
Approach, rather than language (Score:4, Insightful)by middlefeng ( 5826674 ) on Monday March 25, 2019 @12:05AM (#58328620)Around 99% of vulnerability happens in parsing (general speaking, including string handling). If you make decision to take Lua as the format and take Lua parser as parser, done. Almost zero vulnerability.Share
Modules (Score:3, Interesting)by Antique Geekmeister( 740220 ) on Monday March 25, 2019 @01:00AM (#58328806)I’d list all of the public and semi-public repositories that publish modules for automatic installation and update. These include pip, ant, maven, gradle, CPAN, and gems. The Java repositories used by ant, maven, and gradle tend to have unknown binaries and unknown provenance, with no reliable way to evactly recreate the published jar files. Ruby gems have a similar issue. CPAN and pip rely on upstream source code for local deployment or compilation but are also very vulnerable to their default download of the most recent version of any module, which may or may not interact badly with other obsolete or updated modules. It’s why many operating systems publish packaged binaries, and it’s why the “compile as needed” operating systems cannot be stable and _cannot_ be thoroughly secured.Share
- Re:Don’t forget npmjs. npmjs comes with the added bonus that a ranting author can delete all versions of all of their modules thus breaking previously working installations.
  - Re:Wouldn’t that merely break new deployments of those modules? I’d not expect it to break already deployed systems.
    - Re:Not when it comes to build servers. npm ci deletes the node_modules folder and downloads all the packages again from scratch. You need to turn off npm ci build step and commit hundreds of megabytes (or more) of node modules to your VCS to ensure reliable builds.
- Re:The Java repositories used by ant, maven, and gradle tend to have unknown binaries and unknown provenance, with no reliable way to evactly recreate the published jar files.
  That is nonsense.
  First of all the source code comes from a source code control system, secondly if you use maven/gradle then the jar repository usually always contains a code.jar and a source.jar (and the ‘make file’ to make one from the other).
This is nonsense (Score:3)by gweihir( 88907 ) on Monday March 25, 2019 @01:15AM (#58328844)First, usage is not evenly distributed. Second, some things you can only do in one language. And third, there are different groups of coders for each language. Take C coders, for example. If you use established Linux kernel core coders, you get completely different numbers compared to using newbie kernel driver coders.And then you have that vulnerability is not the same as vulnerability. Simple counting metrics are basically always fundamentally flawed and give you a completely unrealistic picture. If both an easily usable remote vulnerability with privilege escalation is counted the same as a very hard to exploit local vulnerability that just allows you read access to some not very critical data, then the result is utterly meaningless. You also get situations were what is one vulnerability in one language counts as several in another, for example because it is a combined vulnerability in a library in one and separate simpler components in another.Hence statistics like this one do a lot of harm by confusing the issue and help not one bit to actually see a fragment of reality. They abstracted too much away. It is like, for example, they judge whether people are good or bad according to their beer brewing skills. You will find good beer brewers that were mass-murderers, and ones that were saints. The results of such an evaluation is completely meaningless.Share
- Re:This is nonsense (Score:4, Interesting)by imidan( 559239 ) on Monday March 25, 2019 @02:38AM (#58329062)If both an easily usable remote vulnerability with privilege escalation is counted the same as a very hard to exploit local vulnerability…I knowingly created a vulnerability in a single sign-on system that I implemented. I did it for expediency. But when I did, I spoke with my boss about it first, and then we all talked about it at a staff meeting to try to determine ways that it could be exploited. The two we came up with involved a bad actor who already had unrestricted physical access to a logged-in user’s machine, or a bad actor who had reality-defying luck at guessing a UUID within a 24-hour period. In either case, the attacker couldn’t gain access beyond the user they impersonated. It was decided that even though a vulnerability existed, successful exploitation was unlikely.The point being, as you say, not all vulnerabilities are made equal. If you can determine the risk of exploitation, the value of the system being protected, and the cost of recovery from a bad action, and accept all of that, then maybe the cost of eliminating the vulnerability is greater than the expected cost of dealing with an exploit.ParentShare
  - Re:As soon as you documented this very carefully and very hard to miss in the code and in the written documentation, I have absolutely no problem with this approach. Competent risk management is not about perfection, it is about balancing cost and risk-costs and avoiding catastrophe-level events.
- Re:Do you? Is that why the top 6 products [cvedetails.com] with the most vulnerabilities in 2018 were all Linux products? Is that why the Linux kernel had the second highest number of vulnerabilities [cvedetails.com] in 2017?
  
  C coders don’t seem to be that great at security.
  - Re:You seem to be functionally illiterate. Because what you criticize is very clearly not what I said. I did, in fact, not make any claim as to Linux security vs. other products. But that seems to have completely escaped you. Which is hilarious, because you even quote the line that you were unable to comprehend.
    - Re:Don’t cry just because C has let you down. Recognize Cs failings and move on to a better language.
      - Re:You continue to be clueless. I did not claim C was a good or bad language either. I just used it to explain a deep flaw in the comparison made.
        Re:Nope, I just occupy the real world as opposed to being siloed in the deluded fantasy you wish the world to be. Where are these mythical programmers that will finally write secure programs in C? Why have they done such a terrible job so far? When will they improve? When will they deliver? When will you deliver anything to back your claims?
        
        It’s time to put up or shut up, kid.
  - Re:You’re conflating two different concepts. We have no way of knowing what piece of code has the highest number of vulnerabilities. To find that out, we would have to freeze all development and then scour all existing code using some standardized methodology.What you’re talking about here is that the Linux kernel had the second highest number of vulnerabilities that were discovered. BIG difference.The Linux kernel is open source and is by far the most widely used operating system in the world. Vulnerabili
  - Re:Read my .sig
Assembler (Score:2)You forgot assembler.
- Re:Assembler is not in the list because it is usually only needed when no other choice is possible.
proper statistics (Score:2)It would’ve been easy to break numbers down by lines of code, wouldn’t it?Likewise by the year the code was written and whether or not it is currently being maintained (say, did the repository get an update within the past 3 months?).
- Re:Bug/loc would just boost the rankings of languages with extra boilerplate.
  - Re:There are a couple LOC counters that ignore comments and don’t count lines with only opening or closing paranthesis etc. etc. – it’s not like this is the first time the issue appears.
Since they are not listed… (Score:3)by LordHighExecutioner ( 4245243 ) on Monday March 25, 2019 @05:27AM (#58329452)…but neverthless have a very large volume of written code, from TFA we can conclude that COBOL and FORTRAN are the safest language to use.Share
Look at Defect Density (Score:5, Insightful)by ytene( 4376651 ) on Monday March 25, 2019 @06:31AM (#58329640)The OP includes the disclaimer that the C++ programming language “tops the list” because it has been in use for the longest and therefore includes the most lines of sample code from which to draw a conclusion…

But a better measure would be defect density , or the number of vulnerabilities found per thousand executable lines of code. An even better measure would then take that data and factor it using an independent vulnerability severity assessment, such as CVSS2.0 (for example).

Even this approach will leave us with concerns. The results could be massively skewed, for example, if the C++ dataset comprised deeply complex code, whilst the PHP sample (for example) were largely comprised of trivial read-only presentation formatting statements. In order to attempt to make such analysis comparable, it would be necessary to compare equivalent functions written in different languages. In this context, by “function”, I am referring to code objects that deliver either identical or similar functionality, such as input validation.

Unfortunately, the variables don’t end there… The OP suggests that code was drawn from a variety of sources, including GitHub, public issues trackers and public development projects… Even the most cursory glance at GitHub projects will easily demonstrate the huge variance in ability of project contributors. This means that it is entirely conceivable for the test results to be distorted by nothing other than the relative ability of contributing programmers.

This is a really nice idea and we should encourage more and better attempts at helping us to understand what it takes to write defect-free code. However, I’m not entirely convinced that this analysis considers all pertinent factors and therefore am not likely to be completely persuaded by the results.

I would also like to better understand the impact of things like good project discipline on the outcome of this analysis. For example, what are the differences between a project which has really strict internal rules for things like variable, object and function naming? How about something as innocuous as code formatting – things like indentation, line wrapping and so on? What about the toolset and platform? The IDE used? The project discipline with regard to code re-use? All of these are “tells” – indicators as to the sort of defect density we should expect. They will not be uniform across randomly sampled software projects.

In my experience [maybe 10 years developing in a 30-year career] I would say that adherence to these sorts of “programming disciplines” is actually [much] more important than the language you use. Unless you pick a turkey of a language, you should be choosing it because it’s philosophy and structure, it’s approach to solving problems, most closely aligns to what you are trying to achieve.

And as a mentor once told me: “Just remember, the fastest, leanest, most efficient and compact piece of code can be replaced by something which is 5% slower, takes up 5% more memory and is 5% less efficient – but which is easy to understand, debug and maintain.”

Quite possibly one of the most useful pieces of advice I’ve ever received…Share
- Re:Correct. In simpler terms: we need to measure the frequency of vulnerabilities per volume of code written by similarly-experienced programmers; the difficulty in teaching people to avoid those vulnerabilities; the ease in which lazy programming can create vulnerabilities; the scope of an exploit; and the stability of executing an exploit. C#, for example, seems to be less vulnerable than Java for…some reason. I don’t know why. Java seems to have failures that it shouldn’t have, and C# should only be b
- Re:You’ve confused C and C++. C was 47%. C++ was 5%. It’s almost as if they aren’t the same language.
*Face palm* (Score:2)So…we’re measuring a language’s security by the applications that were written in it?

Anyone else have an issue with this?
I call BS. You can NOT measure the language’s security via the applications written it in. You MIGHT be able to gauge a languages popularity given the number of applications written for it (I do). You MIGHT be able to determine the effectiveness of a language *IF* you take the number of applications with vulnerabilities and divide that by the total number of applications written
- Re:the problem is engineering competency relative (Score:5, Insightful)by gweihir ( 88907 ) on Monday March 25, 2019 @01:28AM (#58328872)Very true. Also, a bad C coder will just create other vulnerabilities in Java, for example. The problem is with coders that a) have no clue how to do it and b) do not know their limits or are forced to not respect them by stupid management. It comes all down to the coder, not the language. A bad coder will produce insecure code in any language, there is _no_ way to avoid that even if many bad coders continue to believe in the existence of the One True Language (TM) that will finally make them good coders. This quasi-religious belief is built on a futile hope and hot air used by vendors and interest groups to keep it alive.So, let me state again: There is no silver bullet. Good, secure, reliable and maintainable code is only produced by good, experienced and talented coders. These coders are rare, expensive and expect to be treated well. Not having them and trying to do it on the cheap will always be a lot more expensive in the longer run and is a severe management failure. As in any engineering project, in coding, the architects, designers and coders are the most important people, the managers merely serve to deal with management obstacles. They have zero business making tech decisions and if they do that they sabotage the success chances and result quality of the overall project.We, as the human race, generally have this figured out in engineering, with some notable exceptions, e.g. the current mass-murder committed by Boeing management, the Brazilian dam certified to be secure by TÜV Süd, Fuckupshima, etc. But in software engineering, management is not just incompetent (as usual), it is outright demented and completely disconnected from reality. That has to change.Parent Share
  - Re:Duh. You’re the only one I see here claiming there is. The claim is just that some bullets are a little safer that others, which is absolutely true.So you’re saying there is a silver bullet: Good, experienced and talented coders. Except, you know what? That bullet is also silver-plated at best. Electroplated, even. Good, experienced and talented coders also write insecure code. They write less of it, certainly, but they’re not perfect. You know what works the best? A layered strategy: 1. Top-notc
- Re:the problem is engineering competency relative (Score:4, Informative)by theweatherelectric ( 2007596 ) on Monday March 25, 2019 @03:15AM (#58329170)its not hard to write secure cAnd yet 70 percent of all security bugs [zdnet.com] are memory safety issues.
  
  If only there was some kind of language [rust-lang.org] which was designed to reduce memory safety bugs.Parent Share
- Re:Nor the report. I’m curious as well.

21 dangerous pieces of code and programming missteps

Erik ShermanJournalist, Independent

Software powers social networks, controls vast supply chains, gets astronauts to the moon and back, and saves lives. It can also screw up horribly—causing programs to crash, systems to become vulnerable, and entire servers or data centers to go down.

And it doesn’t necessarily take a lot of code to do this—just enough of exactly the wrong thing. Here’s a salute to the truly terrible choices developers have made and, sadly, will make. Sometimes you only learn by making mistakes, but maybe some people can learn from others and spot the pitfalls ahead before they fall in.

System-breaking code

Just a little code can do a lot of damage. This is why you need to know what you’re doing when the safety measures are off.

Delete the company

There may be times that you want to delete an old directory. But when you take out the entire drive, from the root down, in Unix, it’s ugly. Better pray you have a recent backup.

The command:

rm -rf

In context:

sudo rm -rf --no-preserve-root /mnt/hetznerbackup /

The space before the last backslash is what unintentionally caused the self-destruct.

Lose all your customers

“[PHP] comes with a host of functions that are important to turn off unless you specifically need them,” said Job Brown, web team leader of U.K.-based e-commerce vendor Wooden Blinds Direct. That includes the ability to eradicate your entire set of customers. “That semicolon is the difference between dropping your whole customers table rather than just the customer with an ID of 1,” he said.

DROP FROM Customers; where id = 1

One more time

Another example of a potential disaster comes from a Quora answer by Colin Turner, a professor of engineering education at Ulster University. It’s a fork bomb written in C that will repeatedly create other processes until the system completely runs out of resources because there is no condition for termination.

#include int main(void) { while(1) fork(); }

Watch those typos

Over at Stack Exchange, there was a discussion of bad programming mistakes in C. Some of the classics revolve around the theme of having typos in conditional statements that always cause the condition to evaluate to true. Here are a couple of variations. In the first example, variable c is assigned the value 1, while the second example always evaluates to a true condition, so any code always executes:

if (c = 1); if (a == true);

Overlapping scheduled processes

John Chapin of Capital Technology Services remembers a project that called the Unix cron(). The original developer wrote a task to track user activity by the hour. “But there was also an odd condition that the server would inexplicably run out of memory and need to be rebooted every few weeks,” he said. As it turned out, one round of analysis wouldn’t be done before the next started, and eventually the overlapping processes took up all the system resources. His team found the problem and solved it by breaking the processing up into pieces.

Problem:

5 * * * * cd /var/www/myapplication && rake RAILS_ENV=production statistics:calculate

Fixed:

5 5 * * 0 cd /var/www/myapplication && rake RAILS_ENV=production statistics:annual 5 1 * * 0 cd /var/www/myapplication && rake RAILS_ENV=production statistics:monthly 5 1 * * * cd /var/www/myapplication && rake RAILS_ENV=production statistics:weekly 5 * * * * cd /var/www/myapplication && rake RAILS_ENV=production statistics:daily

Way too long

Chapin also had another good nomination, but one that can’t be shown because it won’t fit on a screen, which was the problem. It was in a Ruby on Rails controller that gathered all clients within a set number of days and then would do some processing.

“Every time the query ran, it would roll through an entire table of 250,000 records about 20 times,” taking two minutes, he said. The problem was that the method was all on one line and it was so long that no one could parse it. Reformatting and changing the table’s keys eventually dropped the load time to 10 seconds.

If you could read this line of code, then it wouldn’t be a problem.

Error-ignoring routine

One Stack Exchange poster mentioned a piece of commercial code that kept crashing. The company wondered why. This error-handling (or error-ignoring) routine was the problem:

/* FIXME! */ while (TRUE) ;

Security vulnerabilities

One of the biggest dangers that emerge from coding flaws is making software more vulnerable to attack or misuse.

Opening the door to the system

Chen Levkovich, CEO of Zuznow, says that using the exec command in PHP is a mistake because it can give someone root access. “If you don’t properly pass parameters without thinking about security, there’s a chance someone [could break in],” he said.

Vulnerable:

exec($args, $output, $return_var);

Fixed:

$escaped_command = escapeshellcmd($args); exec($escaped_command, $output, $return_var);

SQL statement passing

According to Oliver Lavery, vice president of research at IMMUNIO, a real-time web application security vendor, directly passing SQL statements opens a door for a SQL insertion attack. “The attacker can cause the program to confuse what it thinks is data and control statements,” Lavery said. By sending a statement to end the data stream, the attacker can then send commands to take control of the system. Instead, pass parameters. Here’s a Java example followed by a better way.

Vulnerable:

sqlQuery='SELECT * FROM custTable WHERE User=' + Username + ' AND Pass=' + password

Fixed:

sqlQuery='SELECT * FROM custTable WHERE User=? AND Pass=?' parameters.add("User", username) parameters.add("Pass", password)

The dangerous curl command

David Pellerin, a senior tech lead with custom software designer TWG, is amazed that the Unix curl command, used for testing or mirroring websites, allows an insecure mode that effectively bypasses SSL/TLS, trusting that all sites are on the up and up. “For local development and testing, this is fine, but my main point is that sometimes these tools get used in production scenarios, and I feel like it should be much harder to bypass these security features than by simply passing in a simple argument like that,” Pellerin said.

$ curl –insecure

Bad hashing

Verifying a password can go wrong easily. Developers may assume that cryptography is enough. “But a lot of times that web application has a config file on the server with the password to the key,” Pellerin said. Even hashing can go wrong, as with the Ruby code below that uses hashing algorithm SHA256 with no salt value. “This is dangerous because many programmers will think, ‘Oh this must be secure—I’m using a one-way hashing function!’ But in reality the hashed data can be cracked in under one second using ‘rainbow tables.’”

require 'digest/sha2' sha256 = Digest::SHA2.new(256) sha256.hexdigest("password")

result = 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8

Now go to the following website:

https://crackstation.net/

Paste in “5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8” (without the quotes), and click “Crack Hashes.”

In one second you get a green message showing the decrypted phrase “password.”

Taking any old filename

Even a simple line of code to upload a file can be a problem when it accepts whatever name a user provides. This is considered one of the top coding errors by the SANS Institute and Mitre. If the file has an extension such as .php rather than .gif or .jpg, the server might treat the file as an executable program (which is probably what it is). Without additional code to restrict the file type (or even do exception checking), the following C snippet is a danger:

fgets (filename_array; filename_length; stdin);

Deliberate sabotage

As Jeff Williams, CTO and co-founder of Contrast Security, wrote in a paper published at the 2009 Black Hat conference, someone might bribe a developer to insert code snippets to cause damage. Testing and review should consider such problems. Here’s an example that would allow a third party to steal a file off a production server:

String x = req.getParameter( "x" ); BufferedReader r = new BufferedReader( new FileReader( x ) ); while ( ( x = r.readLine() ) != null ) resp.getWriter().println( x );

Real-world consequences

While many of the problems discussed above have been theoretical, the next few examples are bugs that actually happened. Perhaps you’ve seen some of those “worst bugs ever” lists. Just recently Delta Airlines’ systems went down, although that was likely due to a power failure at its data center rather than a software bug. But it just illustrates how major software failures are affecting us all the time.

Buffer overflow and ATM dominoes

A C programmer mentioned on this Stack Exchange discussion a problem that appeared through the poorly advised combination of an assumption and use of the strcpy() function without checking the size of a target buffer. When writing the software for a router for credit card transactions, a programmer assumed that a nine-digit string would be long enough for the necessary bank identification number (BIN). Then the bank moved to a ten-digit BIN, and the transaction router crashed with a segmentation fault after the buffer overflow. The entire processing system that depended on the router followed suit, and as a result, all the ATMs of this large bank stopped working for a few hours.

Regex unbound

Little things can become a big problem. The Stack Exchange network had its own problem in July 2016 because of the following regular expression that was supposed to cut Unicode space from the start and end of a line. A “malformed post” with about 20,000 white space characters in a row played badly with the regex engine, which kept cycling through, one space at a time, eating up CPU time, as Stack Exchange explained. The code crashed the site for 34 minutes. Here’s the responsible code:

^[su200c]+|[su200c]+$

Typo takes down site

Brown, from Wooden Blinds Direct, remembers a time he left a semicolon off the end of one line of PHP code. The company has a group of e-commerce sites with a common code base, and all of them crashed simultaneously. “It doesn’t have to be a complex error to take down your systems,” Brown said.

function Oops($arg_1, $arg_2, $arg_3) { return $my_bad }

Backup carousel

Brown saw another problem due to an external backup provider’s scripting. Wooden Blinds runs hourly backups on “fairly hefty” databases, and the vendor hadn’t finished one backup when another was supposed to start. “The provider hadn’t accounted for [such a situation] in their code,” he said. As a result, the backups kept looping until, by 6 am, there were “thousands of backups trying to run.” Things ground to a decisive halt.

Meta madness

One of the biggest problems that Job van der Voort, vice president of product at GitLab, ever saw in practice was at a previous employer. A developer, who had already left the company, created a production system in Ruby using meta programming, with classes creating additional classes based on a few parameters.

“Initially the only reason they started looking at this was because the program was so slow,” he said. A single page of code would make 2,000 database calls rather than the 1 to 25 that would be desired to optimize for speed. It took him a week to get the count down to 500, but eventually the company gave up and began a complete rewrite. Because so many of the classes were virtual and dependent on particular use scenarios, there was nothing permanent to even read, let alone test and debut. Here’s a simple example that van der Voort provided:

a_new_class = Class.new(Object) do attr_accessor :x def initialize(x) puts "Initialized #{self.class} with #{x}" @x = x end end

When old methods go wild

One system that collapsed under the combined weight of a programming mistake and errors in deployment was the trading system of Knight Capital Group. In 2012 the company lost $440 million in 45 minutes “when it sold all the stocks it accidentally bought Wednesday morning because of a computer glitch,” according to The New York Times.

As an SEC administrative proceeding noted, the company was replacing some years-old code that was no longer used but still callable in the application. It also repurposed a flag used in calling the old code. When a technician forgot to copy the new code to one server, the old code got activated and started sending child orders to some trading systems. There were no provisions for supervising these problems in general, and technicians took the new code off the other servers, putting the problem into overdrive as all the servers began to make the same error. The company eventually had to sell itself later in the year because of this incident.

Financial code forked over

Financial services can be a tricky area for coding. Lavery, of IMMUNIO, remembers in years past writing a data parser for stock exchanges. In his code he used a fork to create some additional processes. “I got an if/then condition wrong which was a test for when to stop forking,” Lavery said. “It ended up forking endlessly. It took down our system and had hundreds of connections to the back end.” Communications bogged down, which meant clients were losing a lot of money by not completing transactions quickly enough.

Have you ever seen or created a catastrophic bug? Tell us about it in the comments section.

Image credit: Flickr

Keep learning

Keep up with QA’s evolution with the World Quality Report 2020-21.
Put performance engineering into practice withthese top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon’s Buyer’s Guide for Selecting Software Test Automation Tools.
Equip your app sec tool belt with TechBeacon’s Guide to Application Security Tools 2021.
Discover best practices for reducing software defects with TechBeacon’s Guide.
Take your testing career to the next level. TechBeacon’s Careers Topic Center provides expert advice to prepare you for your next move.

Read more articles about: App Dev & Testing, Security

Security Blogwatch

Trojan Shield: FBI punks crims with faux app—and international help

by Richi Jennings

When algorithms face reality

Is differential privacy dead? Census case holds lessons for your organization

by Peter Wayner

Don’t take shortcuts

In-depth app sec analysis comes at a cost—but so does a breach

by Stan Wisseman

CONFERENCEWebinar: The road to autonomous IAM Identity and Access Management today is too hard. But there is a better way. Join this June 16 Webinar, or replay after, to learn how. Join Webinar CONFERENCEWebinar: Discover a secure and compliant approach to test data…Ali ElKortobi and Eric Popiel share how to get compliant with sensitive structured data in test/dev. This June 9 webinar will be available for replay. Join the discussion

Get the best of TechBeacon, from App Dev & Testing to Security, delivered weekly.SUBSCRIBE FeaturedSocial engineering isn’t only for normies. Whether you’re an IT puke, an Agile Dev(Sec)Ops sprinter, or a 1337 haxor: Question everything.

Security Blogwatch

APT team attacks white hats: Google fingers North Korea

by Richi Jennings

Bolster your app sec front lines

Starting with SAST: 4 reasons code analysis remains king

by James Rabon

Keep your teams up to speed

The best security conferences of 2021

by Linda Rosencrance

Home

Brought to you by
HP

Topics

TechBeacon

TechBeacon uses cookies to ensure you get the best possible online experience. Continue

Do you want to be the first to read our new TechBeacon articles?YESNO THANKS

ProgrammerSought

Who is the king of bugs: The four most dangerous programming languages, PHP is not the language with the most bugs!

tags: A gathering place for programming enthusiasts Programming language bug

In addition to the investment and attention of Google and Apple in the field of application security, there is also a deep-seated reason that caused the widespread outbreak of iOS vulnerabilities and the security of Android counterattack, that is the security of programming language platforms and open source libraries problem.

King of Bugs

According to the latest annual software security status report released by Veracode, 70% of all application software in the world contains security defects/vulnerabilities caused by at least one open source code base. The software defect density of the Swift code base (the number of defects per code base) Has surpassed the “food and clothing parents” of web security professionals-PHP. (The following figure)

Veracode’s software security status report pointed out that these open source libraries (a free centralized code repository that provides developers with ready-made application “building blocks”) are not only ubiquitous, but also risky.

The analysis examined 351,000 external libraries in 85,000 applications and found that open source libraries are very common. For example, most JavaScript applications contain hundreds of open source libraries, and some even contain more than 1,000 different libraries. In addition, most languages have the same core library set.

The report said: “Especially JavaScript and PHP, there are several core libraries in almost every application.”

Like other software, these libraries have bugs. The problem is that because of code reuse, a single bug may affect hundreds of applications.

Veracode said: “In almost all applications today, open source libraries are very important. It allows developers to speed up development by quickly adding basic functions.” “In fact, without these libraries, it is almost impossible to use software to innovate. It is possible. However, the lack of proper use of open source libraries and the necessary risk awareness has become a serious problem.”

Four most dangerous languages

According to the report, the four main languages with the most bugs in the open source code base are:Swift, .NET, Go and PHP(Above).

Among them, Swift has the highest bug density (7), while PHP vulnerabilities are the most widely distributed (covering nearly 60% of the code base). Because Swift is a professional development language in the Apple ecosystem, although its bug density is high, its distribution is not widespread.

.NET has the lowest percentage of bug distribution among these four libraries (less than 10%), but its code base is more than 17 times that of Swift.

Go contains a high percentage of libraries with bugs, close to PHP, but the average total number of bugs per code library is low. Compared with Go, PHP has a higher number of bugs per code base (6.5), and the bug density is twice that of the latter.

However, in terms of the number of available PoCs, Swift’s performance is not the worst, and PHP is still the undisputed “king”:

The best defense: timely updates

The report also found that cross-site scripting (XSS) is the most common vulnerability category in open source libraries, accounting for nearly 30%, followed by insecure deserialization (23.5%) and access control intrusion (20.3%), as shown in the following figure:

“Unsafe deserialization(Insecure Deserialization) was a relatively rare defect in self-developed applications in the past, and its rapid rise in ranking is disturbing, because such defects may cause unexpected code paths to be executed, which means that some parts of the library that we do not intend to use are also It may be inserted into the execution path of its application. “

The data also shows that due to the cascading interdependence, most of the defective libraries eventually exist indirectly in the form of code, because the open source library used by the developer is likely to call the code of another open source library.

“47% of the defective libraries in the application are transitive. In other words, they are not directly introduced by the developer, but by the first library called (42% are directly introduced, 12% Was introduced indirectly). This means that developers are introducing more code than expected, and often buggy code.”

The good news is that most of the most serious program vulnerabilities and bugs can be resolved through updates (picture below).

“Only minor version updates can solve most of the introduced bugs in the application (nearly 75%); according to the Veracode report, bug fixes usually do not need to upgrade the main program library, and more than 90% of the OWASP TOP 10 The most serious bugs on the list have patches or updates available today.”

Finally, whether you are a career change, beginner or advanced, if you want to learn programming~

【Worthy of attention】mineC/C++ programming learning exchange club!【click to enter】

Questions and answers, learning exchanges, technical discussions, and a large collection of programming resources, and the zero-based video is also great~

Golang tcp forwarding remoteAddr error

Intelligent Recommendation

On the most primitive use of OD-find program bugs

Talk todayODThe original intention of the original author of the debugger to develop the software is to find a programBUG. Of course, this software is now mainly used for program cracking and writing …

Who says PHP is the most penetrating language in the world?

It takes about 10 minutes to read this article. I recently encountered a problem on Zhihu: In the following answer, many people have this idea: the security of the application developed by PHP is not …

2018 most future career prospects Ranking in programming languages, PHP list, but not the C language!

Recently, the 2018 employment prospects most of the seven released a list of programming languages. The programming language rankings are published by Coding Dojo (coding dojo). The programming langua…

2020 most influential four kinds of programming languages, average salary 20K +!

Gold and three silver four so-called “job-hopping season,” every year at this time to see a large number of people choose to leave, is often asked: “? Why should we look for a new job.&…

Programming Language Ranking-The most popular programming languages in 2020

Nowadays, the majority of users prefer to use mobile applications to obtain the products and information they care about. And mobile applications have also become the key to the success of enterprises…https://780f0055d39ba857852b9856e6ca9032.safeframe.googlesyndication.com/safeframe/1-0-38/html/container.html

More Recommendation

Bugs

In a class’s __init__, a property is an object of another class, self.attribute=Class(). When the property is called in an instance method in the class, it is said that there is no such property. I th…

No bugs

Engineer has no bugs iOS engineers have no bugs, Android engineers have no bugs, algorithm engineers have no bugs, applet engineers have no bugs, front-end engineers have no bugs, background engineers…

Bugs

reptile reuqests library import requests #Build parameters kw={“kw”:”Great Wall”} headers={“User-Agent”:“Moz…”} proxies={ “http”:“h…

bugs

Problem Description: Pull image download speed from docker hub is slow Cause Analysis: Overseas server, slow domestic access solution: Change source…

One of the most classic computer programming languages C language

C language is one of the most classic computer programming languages. It is not wrong to develop it in the IT industry. If you are in high school, he can lay a solid foundation for yourself. After wor…

Copyright © 2018-2021 – All Rights Reserved – www.programmersought.com

Notifications Powered by iZooto

https://tags.crwdcntrl.net/lt/shared/2/lt.iframe.html?c=3825

Live Cyber Attack Lab ? Watch our IR team detect & respond to a rogue insider trying to steal data! Choose a Session X

Top Five Most Dangerous Software Errors

IT PROS

Inside Out Security Blog » IT Pros » Top Five Most Dangerous Software Errors

ANDY GREEN

UPDATED: 3/29/2020

Over the years, Mitre, the MIT research group, has been analyzing software bugs and missteps that hackers have been able to exploit. Their Common Vulnerabilities and Exposures (CVE) classifications are something of a de-facto standard used for describing the root software causes in an attack. Working with SANS, the Mitre CVE team has come up with a list of the Top 25 Most Dangerous Programming Errors. Below we take a journey through the top five.

1. SQL as a Lethal Weapon

Who would have thought that SQL, a database query language, has a dangerous side? SQL Injection works by taking advantage of bad web application code that fails to sanitize user input. Any input that comes from a user (e.g., a search term in a search box) cannot be trusted. More specifically, raw user input should never be used in a SQL command string. Ever.

Get the Free Pen Testing Active Directory Environments EBook

“This really opened my eyes to AD security in a way defensive work never did.”

For example, in http://abankcompany.com?tag=pci, the part after the “?” might contain additional toxic SQL commands that, if not properly sanitized by the backend web code, could cause serious damage.

A request containing: http://abankcompany.com?tag=pci union select 1,2,3 would reveal data in columns of a table off limits to users. Or even more maliciously, www.abankcompany.com?tag=pci; drop table user; could be used to remove a key table.

Luckily, most modern web programming frameworks provide built-in methods for validating user input, though nothing prevents programmers from ignoring them.

You can read more here about how to test your web site for this deadly vulnerability.

And in real life, perhaps …

2. Ninja OS Commands

An OS Injection vulnerability is somewhat similar to the SQL variant, but this time hackers convince erroneous applications to execute commands at the OS level instead of the database level. Again the problem is improper validation of input, and hackers are then able to sneak extra commands through the app interface.

If the app runs at a higher-privilege level, this can be a backdoor into running shell commands— say, the mortal rm –rf *.*— with root access permissions

One way to defend against OS injections is to use whitelists—a restricted set of commands that can be executed by the app or server. For example, in Microsoft Windows there are software restriction policies accessible in the Group Policy Object (GPO) editor to control the commands and APIs that an app can execute, thereby preventing it from going rouge.

Software Restriction Policies in the GPO Editor

Source: http://technet.microsoft.com/en-us/library/cc786941(v=ws.10).aspx

3. Stack Attack

Buffer Overflow is a classic hacker exploit that’s been around since the dawn of the Internet. It is somewhat similar to the previous attack, but it focuses on vulnerable computer languages—especially C and C++.

To understand how it works, you have to get very much into the weeds of computer language runtime environments. This one cleverly takes advantage of a lack of checks on storage boundaries in the C language family. Our diagram below explains it all.

Special runtime consistency checks or whitelists (see above) are effective in preventing or limiting the damage of these types of attacks.

4. Crossover Hit

Mitre calls Cross-site Scripting (XSS) “one of the most prevalent, obstinate, and dangerous vulnerabilities”. When we’re browsing, we assume that the web page that comes back, along with any scripts embedded in it, originate from that site or domain. But that’s not the case when hackers do their work.

As in SQL Injection, Cross-site Scripting wedges code—generally Javascript, but also other web languages–directly into the URL. Web pages are often dynamic—generated by PHP, Python, ASP, etc.—and hackers find weaknesses in the server-side web page software to allow their own scripts to be directly inserted.

How do you stop this attack? The Open Web Application Security Project (OWASP) has their own XSS “cheat sheet” that lists the bad HTML with holes that allows the scripts to be injected.

5. Come on in!

Let’s say your company has web software that’s performing critical functions—creating a new bank account, transferring funds, or displaying sensitive financial information. Of course, the app initially checks authentication when the user logs in. But either the actual software is not doing authentication checks or is not using a standardized authentication function at the point in the software where a critical transaction is done.

Result: hackers exploit weak or improper authentication code in order to manipulate critical parameters used by the software. Typically, this is done by directly passing parameters in the URL—again, similar to the SQL Injection attack—or else by manipulating parameters in a web cookie.

Mitre recommends using standardized libraries to carry out these authentication checks rather than relying on customized or ad-hoc approaches.

What’s wrong with this code?

Click here for answer

Source: http://cwe.mitre.org/data/definitions/287.html

Image credits: Panoramic Tiger, Cindy Ng Andy Green

ANDY GREEN

Andy blogs about data privacy and security regulations. He also loves writing about malware threats and what it means for IT security.

——— RELATED POSTS ———

IT PROS

Last Week in Microsoft Azure: Week of June 7th

IT PROS

Last Week in Microsoft Azure: Week of May 31st

IT PROS

The Dawn Of The Four-Minute Cyberattack: Four Steps To Protect Your Company

IT PROS

Last Week in Microsoft Azure: Week of May 24th

Does your cybersecurity start at the heart?

Get a highly customized data risk assessment run by engineers who are obsessed with data security.SCHEDULE NOW

This site uses cookies to provide you with a better browsing experience. Further information may be found in the Varonis Site Privacy Policy Accept

TECH NEWS
PC & MOBILE
LIFESTYLE
HARDWARE
FREE STUFF
VIDEOS
ABOUT

The Worst and Hardest Programming Languages to Avoid Like the Plague

BY IAN BUCKLEYPUBLISHED MAR 09, 2019

Coding is tough. Before you start, know which of the worst and hardest programming languages to avoid. You can thank me later.

There are lots of awesome programming tutorials out there to get you started with coding. But before you dive into them, you’ll have to answer a very difficult question: Which programming language should I learn?

Some languages are easier for beginners to learn. Others are most useful for the future. And others are most likely to help you land a programming job.

In this article, we’ll approach it from the opposite end: Which programming languages should you avoid?

1. Esoteric as %^&*!

Let’s start with an easy one. Esoteric programming languages (or esolang for short) are designed to push programming to its limits of simplicity. In doing so they succeed in making it incredibly complicated.

While this seems like a contradiction in terms, a quick look at the unfortunately named Brainf&*k language:

++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.

This monstrosity is functional, Turing-complete code. The function of this program? It prints Hello World! to the screen. Simple, isn’t it?

The language consists of eight characters, which move the data pointer within the program array, and modify or output the data held in each position. This all adds up to a simple language which is an absolute mind destroyer to use. Hence the unfortunate name. By the way, Brainf£$k is not the only esoteric language with a “colorful” name, so be curious at your own risk!

Brainf^&k is one of the better known esoteric programming languages, though many more can be found. Perhaps you want to build a program using the one-liners of Arnold Schwarzenegger? Chef is particularly notable as the code you write ends up reading like a recipe.

Esoteric languages are designed more like a fun challenge to programmers than for everyday use. As a general rule, these languages are Turing Tarpits and will cause more frustration than anything else if used for actual programming tasks. In the same way that going over Niagara Falls in a barrel isn’t necessary, I’m sure some of you will program in esoteric languages regardless!

2. PHP

This is where things may get contentious. PHP is a server-side language designed for web development, so you can use it to build a simple PHP website. Originally released in 1997, PHP quickly took over the web. You’d be hard pushed to find any large web entity that doesn’t use PHP. PHP introduced the concept of Dynamic Websites, allowing users to query databases in real time rather than loading static pages on each interaction.

A recent Stack Overflow survey shows PHP as the ninth most popular language, and there is still a considerable demand for PHP developers. So far so good. Widely used, in demand, long-standing, what isn’t there to like?

Well, depending on who you ask, quite a lot!

Inconsistency

PHP wasn’t meant to be a language and grew piece by piece rather than with a general structure. This makes learning PHP a frustrating experience.

An example of this provided by aptly named phpsadness is PHP’s get function:

gettype()
get_class()

These little inconsistencies in the naming of in-built functions are part of a much larger problem. Small differences in syntax and semantics make PHP difficult to learn when coming from another language.

In an age of programming language polyglots, these issues might not be a big deal to you, but it is enough to make some developers run for the hills.

One more thing before we move away from these types of inconsistencies. In PHP, function and class names are not case sensitive, but variables are.

Wait, what?

The Ternary Operator

Whether it is a product of PHP’s ad-hoc structure or the mad whim of one of its creators, the ternary operator in PHP is baffling. Consider this:

$a = 11; 
echo ( 
    $a == 10 ? 'ten' : 
    $a == 11 ? 'eleven' : 
    $a == 12 ? 'twelve' : 
    $a == 13 ? 'thirteen' : 'something else'); 
echo "
";
//this code prints 'thirteen' to the console

As you can see in the above example, PHP does strange things with ternary operators. In almost all other languages you would expect this code to output eleven. PHP disagrees.

This strange behavior comes from PHP using a left associative ternary operator. This somewhat mind-bending behavior is utterly unintuitive to many programmers, and even after reading a detailed explanation of how it works, it’s still baffling.

PHP is still used widely, and many people claim it has improved hugely over its 20-year tenure.

If you want to create your own WordPress plugins, then it’s certainly worth learning. There are great resources out there to get you started learning PHP, and its popularity means you will likely land a development job once you have.

The real question is: with so many other languages out there, and the rise of other frameworks like node.js and Ruby on Rails, do you really want to?

3. JavaScript

Can you hear that? It’s the sound of a thousand developers cracking their knuckles, ready to defend JavaScript’s honor in the comment section!

JavaScript is the language of the internet. There is no disguising its dominance. If you are using a browser, the page you are looking it will almost certainly be using JavaScript. When you watch Netflix or use PayPal, you are using servers running node.js, JavaScript’s server-side runtime. A quick skim of any job board for programmers shows demand for JavaScript developers.

Why does it belong on this list? Well, the darling of front-end has a few quirks.

Automatic Semicolon Insertion

If you are familiar with Java or any of the C family programming languages, you’ll know that semicolons are used to denote the termination of a statement. The interpreter sees the semicolon and knows to move on.

In JavaScript things are a little different. Semicolons are optional. While that might seem impossible, many people want to drop semicolons from JavaScript altogether.

While this is a nice idea, it is not without its problems. Self-confessed semicolon denier and YouTuber Kyle Robinson Young makes a good case for why they should be used by beginners.https://www.youtube.com/embed/gsfbh17Ax9I

The issues raised in this video point to a wider problem. JavaScript works fine without semicolons most of the time. This is because the semicolons aren’t gone at all, they are just automatically inserted where the interpreter thinks they should go.

While the cases when the interpreter gets it wrong are seen as “edge cases” by more experienced coders, they are all things beginners are likely to run into, thereby making the experience of using JavaScript unwelcoming.

A short search on the subject of semicolons in JavaScript will lead you down a rabbit hole of opinion and speculation with almost no end. When a language requires a full page of reading just to understand where you should use a semicolon, only to conclude that you should make up your own mind, it’s forgivable to think that something is wrong!

An Array of Weirdness

Anyone who has taken a beginner coding class will be familiar with arrays. They are a simple way to collect lots of data of the same type and order them to easily get it back later.

This is a fundamental of programming, so they should be pretty simple to understand right? Actually no, not right. The first example in James Mickins’ hilarious talk on JavaScript sums it up nicely:https://www.youtube.com/embed/D5xh0ZIEUOE

“JavaScript arrays are array-list-dictionary combined multi-type objects.”

Right then. Clear as day.

These are just a few small examples of why JavaScript could be seen as a terrible language to learn and to use. For every case here, and the thousands of others all over the web, there is an army of people ready to defend these behaviors. One thing is for sure, JavaScript isn’t going anywhere, and neither are the endless online arguments about it.

For a final bit of fun, which harks back to esoteric languages discussed earlier: open up a JavaScript console in your web browser and paste in this monster:

alert((![]+[])[+[]]+(![]+[])[+!+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]);

A World of Programming Languages

Can you hear the sabers rattling? The angry devs ready to strike down every point made in this article? In truth, they would not be wrong. There are thousands of other cases in almost every language out there I could have used.

With the exception of the esoteric languages, each programming language has its good and bad points. As with all tools, a feature which makes one user’s blood boil is a cherished functionality to another. Semicolons may be one person’s kryptonite, whereas whitespace might keep others up at night.

For a beginner, any programming language is hard, and you should spend time learning the fundamentals of programming before worrying too much about what language to choose. Having said that, it’s important to stay informed about the latest languages that are becoming popular. Right now, Rust is the most exciting programming language to explore!

Image Credit: fizkes/DepositphotosSHARETWEETEMAIL Google TV Could Soon Let You Turn Your Smart TV Into a Dumb OneA “Basic TV” mode could remove all of the smart features from your smart TV.READ NEXTRELATED TOPICS

ABOUT THE AUTHOR

Ian Buckley (214 Articles Published)

Ian Buckley is a freelance journalist, musician, performer and video producer living in Berlin, Germany. When he’s not writing or on stage, he’s tinkering with DIY electronics or code in the hope of becoming a mad scientist.More From Ian Buckley

SUBSCRIBE TO OUR NEWSLETTER

Join our newsletter for tech tips, reviews, free ebooks, and exclusive deals!SUBMIT

ON THE WIRE

How to Use Chrome Extensions on Android Mobile Browsers

What You Need to Know About Android Auto

How to Use a Fake IP Address and Mask Yourself Online

TRENDING NOW

Microsoft Leaker Hints at “the New Windows” Coming Soon

Save $200 on the OnePlus 8T Every Wednesday Through June

You Can Now Add Pronouns to Your Pinterest Profile

10 Useful iPhone Tips for Seniors

What Is Zelle and Is It Safe to Use?

How to Schedule the Blue Light Filter on Android

5 Real-World Use Cases for NFTs in the Future

Microsoft Is Already Working on the Surface Duo 2

Is WordPress Still Worth Using in 2021?

Universal Control: Apple’s Exciting Feature Seamlessly Links Your iPad and Mac Together

The 7 Best Smart TVs in 2021

4 Programming Languages Every Cyber Security Professional Must Know

22/05/2019

Google Reveals That Some G Suite Passwords Were Stored In Plaintext Since 2005

Technology is playing a significant role in our day to day life, and with that, the world is becoming extensively connected —whether it’s about talking to a closed ones living overseas or it’s about asking your AI assistant to turn off the lights of your bedroom. However, there lie a somethings that we should be worried about — cybercriminals are strengthening their skills to compromise every single system (whether it belongs to an organisation or an individual). And the number of cyber-attacks in recent time is evidence why it is high time to focus not only on innovation and advancement in technology but also on the elimination or mitigation of cybercrime.

Today, the need for cybersecurity professionals are more than ever. However, the industry is dealing with a talent crunch and one of the reasons behind this is the limited knowledge of programming. You all must be wondering, is it really necessary to have a programming language knowledge to have a cybersecurity career? Well, the answer is yes! And in this article, we are going to see why cybersecurity professionals should know programming and what are some of the best programming languages to master.

Why Programming Is Important In Cyber Security

Cybersecurity is not just about using a customised operating system with hundreds of tools to find vulnerabilities — it is something more than that. You want to be a top-notch you have to think like a hacker and look for all the possible ways a hacker could exploit any system, and this includes development too.

One cannot simply become a computer scientist if s/he do not know a programming language and cybersecurity is no exception. When you master programming, you move one more step closer to become a top cybersecurity professional. It helps you unlocks the mysteries behind an attack and defend against some of the most dangerous hacking techniques. That’s why coding is a sought-after skill in the cyber security sector.

Some Of The Most Sought After Programming Languages For Cyber Security

JavaScript

JavaScript is a high-level and one of the most popular programming language for the web. Almost every website today is JavaScript backed. And why not? It is the “Lingua Franca” of the web that adds interactivity to websites.

If you want to work with cookies, manipulation of event handlers, and perform cross-site scripting (XSS), JavaScript is for you. XSS is one of the most popular hacking technique when it comes to compromising a website. The hacker usually looks for an input flaw on the website and if there is one, the hacker uses scripts to take over the website.

So, if you have a strong hand on JavaScript, you can make sure that the website is secure enough to mitigate or even eliminate XSS attacks.

Structured Query Language (SQL)

For every business a database is critical and today, with business enterprises getting more data-driven, and most database management systems are powered by SQL. Structured Query Language (SQL) is the most sought after programming language when it comes to managing databases. So, how would it help a cybersecurity professional? Most of the hackers at present are working day in and out to exploit databases and when you master the sorcery of SQL, you can help to make databases more secure.

SQL injection attacks are one of the widely used hacking technique. Hackers look for SQL vulnerability and then exploit it. So, a cybersecurity professional with a significant amount of SQL can help to fix those vulnerabilities. SEE ALSO

DEVELOPERS CORNER

10 Best Python Libraries For Computer Vision

Python

Python over the years has become a very popular programming language. Not just among data science professionals but this a high-level language is also increasingly becoming popular among cybersecurity experts. Code readability, clear and simple syntax and an extensive number of libraries are some of the factors that make it sought after.

So, when you are a cybersecurity expert with Python programming knowledge, you can build attack simulations, intrusion detection systems and also, scan wireless networks without relying on third-party tools. So, you don’t remain a Scrip Kiddie for life.

C & C++

When you are from the computer science background, it by default becomes a must-know language for you. Being low-level programming languages, C and C++ provide access to low-level IT infrastructure that is not well protected and can easily be exploited.

If you are a highly experienced in these two languages, it becomes easy for you to respond to attacks targeting lower level operations. It also helps you in reverse-engineering and finding vulnerabilities. So, if you are a cybersecurity professional, make sure you have an upper hand on C and C++.What Do You Think?https://web.facebook.com/v10.0/plugins/comments.php?app_id=224833517628762&channel=https%3A%2F%2Fstaticxx.facebook.com%2Fx%2Fconnect%2Fxd_arbiter%2F%3Fversion%3D46%23cb%3Df2134f694005388%26domain%3Danalyticsindiamag.com%26origin%3Dhttps%253A%252F%252Fanalyticsindiamag.com%252Ff330eba6f43ff%26relation%3Dparent.parent&container_width=690&height=100&href=https%3A%2F%2Fanalyticsindiamag.com%2F4-programming-languages-every-cyber-security-professional-must-know%2F&locale=en_US&numposts=5&order_by=social&sdk=joey&version=v10.0&width=

Join Our Telegram Group. Be part of an engaging online community. Join Here.

Subscribe to our Newsletter

Get the latest updates and relevant offers by sharing your email.HARSHAJIT SARMAH

Harshajit is a writer / blogger / vlogger. A passionate music lover whose talents range from dance to video making to cooking. Football runs in his blood. Like literally! He is also a self-proclaimed technician and likes repairing and fixing stuff. When he is not writing or making videos, you can find him reading books/blogs or watching videos that motivate him or teaches him new things.SHARE TWEET

OUR UPCOMING EVENTS

Webinar

Data Science Skills In The Post-COVID World

11th June

Free Workshop

oneAPI AI Analytics Toolkit

17Jun

List

Top Data Science Service Providers In India – 2021

Share Nominations>>

Research

State of AI in the Enterprise in India

Fill the Survey>>

List

Most influential Analytics Leaders in India. Analytics100 Awards 2021

Share Nominations>>

Behind The Code: This Developer Who Began His Journey With Flipkart Tells Why DevOps Is A Good Career

NEWS

Google Reveals That Some G Suite Passwords Were Stored In Plaintext Since 2005

OPINIONS

What Is The New Google OS Fuchsia All About

04/06/2021
3 MINS READ

OPINIONS

Best Programming Languages To Build Chatbots

01/06/2021
3 MINS READ

DEVELOPERS CORNER

Ultimate Guide To Recursion And Iteration In Python

26/05/2021
7 MINS READ

OPINIONS

What is IBM’s Project CodeNet?

24/05/2021
3 MINS READ

DEVELOPERS CORNER

Beginners Guide To Logistic Regression In Python

23/05/2021
8 MINS READ

DEVELOPERS CORNER

Comprehensive Guide To Dimensionality Reduction For Data Scientists

15/05/2021
6 MINS READ

CONNECT

MENTORSHIP

OUR BRANDS

EVENTS

OUR CONFERENCES

AWARDS

OUR VIDEOS

BRAND PAGES

Intel AI Hub

ASSOCIATION OF DATA SCIENTISTS

LISTS

Tutorials
Student
Jobs
Courses

Sign In
Home
Courses
- Algorithms
- Data Structures
- Languages
- Interview Corner
- GATE
- CS Subjects
- Web Technologies
- School Learning
- Student
- Jobs
GBlog
Puzzles
What’s New ?

Change LanguageRelated Articles

5 Most Difficult Programming Languages of the World

Difficulty Level : Medium
Last Updated : 22 Sep, 2019

You might have written your first code in programming languages such as C/C++ or Java and might have faced difficulty learning these languages. Well, these languages are at least readable or understandable but what if we say to write a program printing ‘Hello World!‘ using spaces, tabs, and linefeeds only. We are not joking and actually there are some programming languages in the world where you need to write your code using some commands or syntax which is neither readable nor understandable. They are also considered as the most difficult programming languages in the world and maybe you will get to know about these languages for the first time so let’s discuss these languages one by one.

1. Brainfuck

As the name suggests, this language is really complicated and coding in this language is really difficult. It was created in 1993 by Urban Muller and the main purpose to create this language was to write minimal lines of code. This language operates in an array of memory cells and there are only 8 commands defined in this language to write any program.

Example: Hello World! Program

++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.——.——–.>+.>.

Check the output of this code from here.

2. Cow

We know that the name of this language sounds a funny name for you but it is actually a programming language and it was created by Sean Heber in 2003. This language consists of 12 instructions and the funniest thing about this language is the keyword ‘moo’ (sound of a cow) or it’s variations used in this language. Writing any other character or word considered as a comment in this language. It was based on the language used in Turing Machine.

Example: Hello World! Program

MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO Moo MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO Moo MoO MoO MoO MoO MoO MoO MoO Moo Moo MoO MoO MoO Moo OOO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO Moo MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO Moo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOoMOo MOo MOo MOo MOo Moo MOo MOo MOo MOo MOo MOo MOo MOo Moo MoO MoO MoO Moo MOo MOo MOo MOo MOo MOo Moo MOo MOo MOo MOo MOo MOo MOo MOo MooOOO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO Moo

Check the output of this code from here.

3. Intercal

This language was created in 1972 by Don Woods and James M. Lyon and they both were students at Princeton University. This language doesn’t have any pronounceable acronym. Creators of this programming language included keywords like Read out, Ignore, Please, Forget, and likewise to make this language user-friendly. The funny thing about this language is that it expects 4 Please keyword in code to check programmers politeness. If it will be less the code won’t execute because it will consider the programmer is insufficiently polite. If it will be 5 or more than 5 then also it won’t execute because it will consider the programmer is overly polite.

Example: Hello World! Program

DO ,1 <- #13
PLEASE DO ,1 SUB #1 <- #238
DO ,1 SUB #2 <- #108
DO ,1 SUB #3 <- #112
DO ,1 SUB #4 <- #0
DO ,1 SUB #5 <- #64
DO ,1 SUB #6 <- #194
DO ,1 SUB #7 <- #48
PLEASE DO ,1 SUB #8 <- #22
DO ,1 SUB #9 <- #248
DO ,1 SUB #10 <- #168
DO ,1 SUB #11 <- #24
DO ,1 SUB #12 <- #16
DO ,1 SUB #13 <- #162
PLEASE READ OUT ,1
PLEASE GIVE UP

Check the output of this code from here.

4. Malbolge

This language was introduced by Ben Olmstead in 1998 and the amazing fact is that it took almost two years to write the first program so you can imagine the complexity of this language. Coding in this language looks like garbage or malfunction and it is said to be that Ben Olmstead has never written a single program in this language. Malbolge is a public domain esoteric programming language and considered as one of the hardest programming languages in the world.

Example: Hello World! Program

('&%:9]!~}|z2Vxwv-,POqponl$Hjihf|B@@>,=<M:9&7Y#VV2TSn.Oe*c;(I&%$#"mCBA?zxxv*Pb8`qo42mZF.{Iy*@dD'<;_?!}}|z2VxSSQ

Check the output of this code from here.

5. Whitespace

This language was introduced by Edwin Brady and Chris Morris on 1st April 2003 (April fools day). The day it was introduced people thought it was a joke but it wasn’t actually. You are allowed to use only spaces, tabs, and linefeeds to write your code in this language. Any other character will be ignored by the interpreter.

Example: Hello World! Program. Don’t confuse as the source code only contains the whitespace and tabs. Check the output of this code from here.

Other Difficult Programming Languages:

Try out the all-new GeeksforGeeks Premium!

anuupadhyay @anuupadhyayVote for difficultyCurrent difficulty : MediumEasyNormalMediumHardExpertArticle Tags :

Improve ArticleReport IssueWHAT’S NEWDSA Self Paced CourseLearn DSA with recorded video lectures and aim top product-based companiesView Details Ad free experience with GeeksforGeeks PremiumView Details Basic to Advanced DSA Live ClassesLearn DSA from scratch in these Live Online Classes and get placement readyView Detailshttps://tpc.googlesyndication.com/safeframe/1-0-38/html/container.htmlMOST POPULAR IN GBLOG

MOST VISITED IN PROGRAMMING LANGUAGE

Writing code in comment? Please use ide.geeksforgeeks.org, generate link and share the link here.
Load Comments5th Floor, A-118,
Sector-136, Noida, Uttar Pradesh – 201305feedback@geeksforgeeks.org

@geeksforgeeks , Some rights reservedWe use cookies to ensure you have the best browsing experience on our website. By using our site, you acknowledge that you have read and understood our Cookie Policy & Privacy PolicyGot It !

These are the most insecure programming languages

SECURITY

RELATED STORIES:

RELATED TOPICS:

MORE FROM STEVEN J. VAUGHAN-NICHOLS

NEWSLETTERS

RELATED STORIES

Related Links

Human Resources Software | Compare of the Most Popular HR Software

Related LinksTop of the: day, week, month.

You are here

21 dangerous pieces of code and programming missteps

System-breaking code

Delete the company

Lose all your customers

One more time

Watch those typos

Overlapping scheduled processes

Way too long

Error-ignoring routine

Security vulnerabilities

Opening the door to the system

SQL statement passing

The dangerous curl command

Bad hashing

Taking any old filename

Deliberate sabotage

Real-world consequences

Buffer overflow and ATM dominoes

Regex unbound

Typo takes down site

Backup carousel

Meta madness

When old methods go wild

Financial code forked over

Keep learning

by Richi Jennings

by Peter Wayner

by Stan Wisseman

by Richi Jennings

by James Rabon

by Linda Rosencrance

Topics

TechBeacon

ProgrammerSought

Who is the king of bugs: The four most dangerous programming languages, PHP is not the language with the most bugs!

King of Bugs

Four most dangerous languages

The best defense: timely updates

Intelligent Recommendation

More Recommendation

Copyright © 2018-2021 – All Rights Reserved – www.programmersought.com

Top Five Most Dangerous Software Errors

1. SQL as a Lethal Weapon

Get the Free Pen Testing Active Directory Environments EBook

2. Ninja OS Commands

3. Stack Attack

4. Crossover Hit

5. Come on in!

Does your cybersecurity start at the heart?

The Worst and Hardest Programming Languages to Avoid Like the Plague

1. Esoteric as %^&*!

2. PHP

Inconsistency

The Ternary Operator

3. JavaScript

Automatic Semicolon Insertion

An Array of Weirdness

A World of Programming Languages

SUBSCRIBE TO OUR NEWSLETTER

ON THE WIRE

TRENDING NOW

READ NEXT

4 Programming Languages Every Cyber Security Professional Must Know

READ NEXT

Why Programming Is Important In Cyber Security

Some Of The Most Sought After Programming Languages For Cyber Security

JavaScript

Structured Query Language (SQL)

Python