Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Open Source Programming PHP

Open Source Security Report Finds Library-Induced Flaws in 70% of Applications (techrepublic.com) 44

Posted by EditorDavid from the public-libraries dept.
The State of Software Security (SOSS): Open Source Edition "analyzed the component open source libraries across the Veracode platform database of 85,000 applications which includes 351,000 unique external libraries," reports TechRepublic. "Chris Eng, chief research officer at Veracode, said open source software has a surprising variety of flaws." "An application's attack surface is not limited to its own code and the code of explicitly included libraries, because those libraries have their own dependencies," he said. The study found that 70% of applications have a security flaw in an open source library on an initial scan.
Other findings from the report:
  • The most commonly included libraries are present in over 75% of applications for each language.
  • 47% of those flawed libraries in applications are transitive.
  • More than 61% of flawed libraries in JavaScript contain vulnerabilities without corresponding common vulnerabilities and exposures (CVEs).
  • Fixing most library-introduced flaws can be done with a minor version upgrade.
  • Using any given PHP library has a greater than 50% chance of bringing a security flaw along with it.

This discussion has been archived. No new comments can be posted.

Open Source Security Report Finds Library-Induced Flaws in 70% of Applications More

Open Source Security Report Finds Library-Induced Flaws in 70% of Applications

Comments Filter:

  • For the record, I have always been opposed. You should buy all your JavaScript and PHP code directly from me.

  • Well now (Score:5, Funny)

    by 93 Escort Wagon ( 326346 ) on Sunday May 24, 2020 @02:48AM (#60097676)

    "Using any given PHP library has a greater than 50% chance of bringing a security flaw along with it."

    My sincere congratulations to the PHP team for improving their security by a whopping 50%!

    • Re:Well now (Score:5, Interesting)

      by Z00L00K ( 682162 ) on Sunday May 24, 2020 @04:53AM (#60097866) Homepage Journal

      To me it feels like we are always re-inventing the need to do a security analysis of the things we work with.

      And one thing that worries me a bit is that libraries in PHP and JavaScript may not show any signs of defects until you actually execute the code. In compiling languages like Java and C# you have the opportunity to detect a number of issues at compile time.

      Of course - regardless of which language you use you have to be careful with how you treat the language. Only expose information that's needed, verify that incoming data is sane and make sure you have a good type safety. Personally I prefer strong static typing because then I will directly get an indication whenever there's a mistake in the code. Some code mistakes done in scripting languages can only be detected in testing using Special Circumstances (Iain M. Banks would love that) while those mistakes would be discovered at compile time if you use a compiling language.

      For developers of Java it's a good idea to also use SpotBugs [github.io], set maximum level of warnings in the compiler (Eclipse have a huge number) and keep classes small and concise. Same goes for C# where Visual Studio has a pretty good built-in analyzer and then add StyleCop [visualstudio.com] to further improve the code and documentation of it.

      Remember - a warning that a compiler emits is a sign that there's something that could give you a problem. Don't ignore it. It's like the flashing yellow lights in an intersection - ignore them all the time and suddenly one day you'd get mangled by a tank.

      • Re: (Score:2)

        by gmack ( 197796 )

        PHP has warnings, most "programmers" ignore them. As a sysadmin, the log output of both commercial and Open Sourced software drives me crazy.

        • Re: (Score:1)

          by Z00L00K ( 682162 )

          And all those warnings are execution-time warnings, not compile-time warnings where they actually makes sense.

        • Re: (Score:1)

          by Cobron ( 712518 )
          Do what my sysadmins do: set the log level to error. No matter how many times I try to explain the difference between fatal (game over), error (txn gone wrong) and warning (something that shouldn't have happened, happened. Still: look into this.), They just stare blankly and respond they're only interested in errors. On the other hand, http 404s in REST services are logged as errors, so there's that o.O

          • Re: (Score:2)

            by gmack ( 197796 )

            The downside of that plan is that what's a warning today could very well be an error tomorrow.

            It also doesn't help that many warnings are attempting to warn the reader about either the possibility of data corruption or a security bug.

          • The problem is a huge amount of notices and warnings should be fatal errors. What's worse than stopping the train and it turning out there wasn't someone on the tracks? There being someone on the tracks and the train not stopping. I turn all notices and warnings into exceptions most of which end up being fatal errors because it means the program encountered an unexpected internal inconsistency and at that point it's in a state it has not been programmed for so rather than have an arbitrary result it gracefu
        • I do both sysadmin and programming which is part the definition of full stack. I find most sysadmins and programmers aren't very good. Though sysadmins end up in a tight position often unable to do anything about code problems then they also lock down their systems making the developers unable to do anything about system problems with both guarding against the other but neither guarding against themselves.

          I always turn warnings and notices into fatal exceptions and enable strict modes where ever I can. N

          • Re: (Score:2)

            by gmack ( 197796 )

            I always turn warnings and notices into fatal exceptions and enable strict modes where ever I can.

            I got called "Code NAZI" for doing that.

      • You absolutely make a good point that strong typing helps make more robust software.

        30 years ago, compiled languages tended to be strongly typed and interpreted languages tended to be weakly typed. So you could say "compiled" when you mean "strongly typed".

        Then byecode happened and most languages use similar processes to go from source code to execution.

        Today, we use the V8 compiler on JavaScript. You compare JavaScript to (scripting language - interpreted?) to Java (compiled). Funny thing - it's actually

        • I've reviewed large-scale compiled applications that consisted largely of many, many calls to Process.Start or similar. Assembling command lines and then executing them for the dumbest things, things that are very easy to do directly

          Very easy is not the same as easiest. C'mon, hit that easy button.

        • Re: (Score:1)

          by Anonymous Coward

          Java is a bytecode interpreter, V8 turns JavaScript into actual machine code.

          This is wrong. First off, Java is a language, JVM is the bytecode interpreter (or Dalvik/ART when using Java on Android).
          Second, while Java does do bytecode interpreting initially, when parts of code get executed multiple times (about 10x iirc), the JIT compiler optimizes that code and compiles it into native instructions. If the execution path changes, the JIT can optimize the byte code once again, and produce optimal native code. This optimized native code runs very fast, near C++ levels.

          • > First off, Java is a language, JVM is the bytecode interpreter (or Dalvik/ART when using Java on Android).

            Try running:
            whereis java

            You'll probably get a result like: /use/bin/java

            Java with a capital letter even I the middle of a sentence is a language. Java with a lowecase letter (or at the beginning of this sentence) is an interpreter.

            • Re: (Score:1)

              by Anonymous Coward

              Well, you just went out of your way to make yourself look like an idiot...

              When people are talking about Java, they mean the language in 100% of the cases. Just because you can rename a binary to just about any string doesn't prove your point. By that logic, I could alias httpd to java and claim "Java is a web server".

              But my first point was just a nitpick, you ignored my main point, which is that Java does compile to machine code, and produces very optimized code. It's a lot more advanced than V8 in many reg

      • For developers of JavaScript, TypeScript - and using it properly - is a wise choice. So, yes, whilst JavaScript doesn't natively support strong static typing, it doesn't mean you can't do it, just do it right.
        One of the ways of using it properly means avoiding the use of 'any' for Types, at all costs - by doing this, you are negating the very reason for having it in the first instance.

        I'd encourage all JavaScript developers to make the switch to TypeScript - sure, there's a learning curve, it can feel like

    • I've found this a lot and to be quite honest it's really difficult to evaluate the real scope of the problem.

      I'm seeing a very large number of security flaws that aren't. A lot of security isn't local especially for libraries. They assume that they're operating behind an application or running on an isolated server.

      In many many cases the flaws in libraries I've seen come about when user data is passed to them blindly in a way that I personally would tend to limit fully or greatly in the application us

  • Composer (Score:3, Interesting)

    by Aethedor ( 973725 ) on Sunday May 24, 2020 @04:34AM (#60097834)
    That's why you should not use tools like Composer blindly. I see developers drag in hundreds of megabytes of ibraries for only one simple function or feature, because they are too lazy do to some research and coding themselves. Also no research in the library's security history, no looking at the code itself, no testing of its security or robustness. If it works, they're fine with it. Although a thing like Composer can be good, the way it's being used now by developers, it's pure evil.

    • It's too late. Everything is an Electron app. Everything ships with its own entire browser and library and OS stack, because you wouldn't want to have dependency conflicts in your string padding function, now would you?

      • This such as electron are pretty good for EPOS. For apps however it's just going to be bloat.

    • npm as well. Last time I dealt with a small Node.js app, it required downloading about 450 modules to build. When I looked at some of those modules, the vast majority of them were literally less than 5 lines of code. The manifest files were way bigger than the source.

      Oh, and every time a new version of the app is released, it refuses to build and it takes hours to sort out the dependency problems. I knew there was a reason I quit doing this crap for a living.

      • I often use rsync heavily for trivial deployments and layered building. Since the rise of NPM and composer what used to be a few thousand files for a major project and about 50MB to 200MB is now millions of files and gigabytes. It often adds easily as much burden as it does benefit. It's very hit and miss if it pays off.
    • I've built entire enterprise systems not using a single PHP library or composer. Though libraries were used they would be either extensions or libraries available on the system rather than PHP libraries. Most composer libraries don't offer you anything that you couldn't make as quickly yourself for a lot of projects. Even libraries for things that you really don't want to DIY tend to be plagued with things such as missing essential bases.

  • Less RAD, more RAD (Score:4, Interesting)

    by Aethedor ( 973725 ) on Sunday May 24, 2020 @04:46AM (#60097860)
    We need less Rapid Application Development and more Robust Application Development.

    • Less of the now clearly stupid "move fast and break things" bullshit.
      Also more of developers working with the business at an agile level, more peer-programming, more peer-reviews and more knowledge spread within a squad.
      IOW, tear down the silo, flatten the waterfall.

  • I may have misunderstood the "snap" technology, but to me it seems that the snap package supplier will have to repackage the whole package to upgrade even one faulty library.

    • Re: (Score:2)

      by Junta ( 36770 )

      Goes beyond snap.

      Basically, this push to 'containerize' applications without even trying to make them sanely installable means that it is pervasive that library fixes cannot be acquired from a distribution but from random application providers.

  • Every time I try to point out a flaw in a library, some old lady shushed me.

    • If you take more than a second to understand what the hell he's talking about, it means you haven't had your coffee yet.

      I'll be right back, going to make myself a drink for completely unrelated reasons.

  • Did we once naively believe there were no flaws in open source software since the ten thousand eyes would find them?

    • ''The authors concluded that "most of these fixes are relatively minor in nature, suggesting that this problem is one of discovery and tracking, not huge refactoring of code."

      When you consider the fact that the codebase is actually auditable in relation to the walled garden one gets with commercial closed source software and the ease of a relatively pain free correction is all the more reason not to use the ''walled gardens''. Hiring super talented staff is much cheaper than paying MS for a commercial lice

    • No. We never did that.

      We assume that more flaws are found in OSS since source code makes it easier to find them.

      This means that well-maintained OSS is likely to have LESS flaws. Not none.

      • Weasel-words alert -- "well-maintained" and "likely".

        I see no reason that "well-maintained" closed source software cannot have similar advantages, along with the one that keeps hackers from examining source directly for flaws.

        • "Weasel-words alert -- "well-maintained" and "likely"."

          You say weasel, I say honesty. I know that's nearly unheard of these days, but try it, you'll like it.

          "I see no reason that "well-maintained" closed source software cannot have similar advantages,"

          There is an obvious reason. It's that the source is closed. No one should even have to point this out to you.

          Much closed-source software is very poorly maintained. Even after disclosure of vulnerabilities to vendors, patches are often a long time coming. This

    • Though there are very serious quality control issues with package systems that optimise for quantity over quality, this study is a bit misleading.

      Quite a lot of the flaws might be problems if the application is lazy in validating what it sends to a library. I see this a lot when I check out the security flaws that get flagged for libraries. Many require the libraries to be more user facing than an application should allow. I don't know exactly how many but it's a fair number that pass my eyes.

      It's als

  • It's Turtles all the way down. (Score:1)

    by Anonymous Coward

    Seriously folks...

    I have buggy code which relies on buggy libraries which rely on buggy libraries which rely on buggy interpreters which rely on buggy compilers which rely on buggy operating systems (and their libraries, which are buggy) which rely on buggy BIOS which rely on buggy microcode which rely on a buggy CPU.

    Meaning, in comparison of Windows, MacOS, Linux, BSD, etc. it's not a comparison of which is better - but which is less bad.

    That we can get *anything* to run > 99% (two-nines) indicates tha

  • Wow, who'd've thought it, using libraries means you inherit their bugs... Oh, and Javascript isn't too good.

Slashdot Top Deals

In the long run, every program becomes rococco, and then rubble. -- Alan Perlis

Close