Full stack, C++, and backend developers in demand in this week's job openings It's Friday and that means it's time for The Reg to run our free job listings We're doing our bit to help keep the global tech workforce in gainful employment during these testing times. So if you're looking to hire some techies anywhere in the world, send your jobs this way and we'll list them for free. No money, no snark. …
Growing or large use does != secure. Wordpress accounts for ~60% of all CMS driven websites, but accounts for ~80% of hacked ones. In a lot of cases they are 'easier' to use by non-programmers and as such are hit on by web-developers who do not have the training or experience in programming.
Amongst many others (like: https://medium.com/commitlog/the-internet-is-at-the-mercy-of-a-handful-of-people-73fac4bc5068, https://snyk.io/blog/node-js-release-fixes-a-critical-http-security-vulnerability/) you have the wheel issue which causes people to use packages and frameworks to do stuff already built in to languages or that is simple to program yourself (without the overflow issues etc. in a lot of libraries), such as the major insecurity found in a package used by most js frameworks and libraries, that simply padded left, something that is built in and has been for a long time. NodeJS allows packages a huge degree of flexibility in their access to the ecosystem for example.
The other issue is the way JS executes client-side and in memory and is susceptible to local re-writing, cache-grabbing, or re-targeting to get the code and look for insecurities, if you must use JS, try to use a lower level, don't use security-based JS or JS that retrieves sensitive data directly, minimise the use of external packages etc. Maybe try to target the dynamic execution side of things, then use it to retrieve the required data from a more secure system that verifies the access.
All languages are susceptible to attack, scripting ones are more so due to the dynamic execution and public access nature of them, however JS libraries/frameworks seem to be particularly flawed, possibly because of the inherent nature of the client-side execution (server side JS is supposed to treat the server as the client, but can be tricked like in the above insecurities report) I mean the last time there was 350 million sites were exposed by the padleft library that had been poisoned, thankfully the people who did this were mostly targeting Wordpress (which included this useless library by default I believe).
To give an idea of the market, one of my client's sites receives about 1000 hack attempts per day, every single one of these attempts targets either HTML form access or JS libraries & frameworks, I have seen numerous try to hit the leftpad issue I mentioned above, many more target specific frameworks like Angular, NodeJS et. al.
>Wordpress accounts for 80% of hacks BECAUSE it is the majority player,
I am not convinced, having in a former (apparently cursed) life, been a web admin for a 100% wordpress webhost, I can assure you that beneath the shiny CMS frontend, wordpress is a horrid insecure mess.
The amount of times I see wordpress do things like "exec($random_byte_string)", or "include $dynamic_path.php" in the code is frightening. It looks like it was programmed by 1st year undergrads as a "learning php" project.
The two things above, coupled with a buggy file_upload.php, most likely results in 99.9% of the hacks on wordpress.
I have seen it, where attackers use a page to send a random php byte string to the underlying exec() function (With no checks or sanitation on wordpresses part), resulting in a compromise.
The other method I have seen them use is to exploit the file_upload.php to upload their own php file, which they then execute by including their PHP in another file with a dynamic include function.
One thing I eventually did was disable exec() in php, which broke wordpress of course. I then went through all of the wordpress code, and rewrote the chunks that depended on exec to make it more secure.
The second thing I then did was make the wordpress web folders read-only to the web browser. This stopped the file_upload compromise. After that we had virtually no problems at all with security.
However, it also meant that (a) you could not install any plugins/themes once set RO, nor upload any files, and (b) some plugins/themes had to themselves be rewritten in order to work without exec.
I maintained this private branch for the company while I worked there, and there were no more compromises (but a lot of moaning from clients for why $free_plugin_X does not work on "our wordpress", and "Why can't I just upload files myself").
The content itself was held in a mysql DB, so once a wordpress site was configured with a theme and media uploaded, the text could be changed by the end user as normal.
So a "secure wordpress" can be done, but it requires a higher skilled developer to do, which is lacking in most of the wordpress ecosystem (especially in the "free themes/plugins" area).
Fact is, even if WP was 10% of the web market, it would still get exploited like now, because their security mistakes are so basic, your average script kiddie can compromise your site.
This post has been deleted by its author
Joomla is a great example of why popularity doesn't matter in this debate, it accounts for about 0.5% of CM website, but is 1-2% of the hacked ones. Showing really poor design and security.
The last couple of JS library issues were both included in standard Wordpress installs and you could attack them using buffer overflow attacks to then execute script command, unsure if the other reply to this response would have stopped that as it would be executing inside the library server-side.
My big point was that a LOT of JS frameworks and CMS's include insecure libraries to do trivial things that are obsolete, such as the padleft library for wordpress which compromised 350+ million websites.
Particularly since padleft can be done natively in js and has been available for some time.
No it doesn't, those are two different points.
1. OP was surprised that a technoglogy that is very popular exists
2. OP assumed JavaScript is magically insecure as a language with no qualifiers. We were talking about server-side JS, so your entire screed about client-side makes no sense at all.
I hate it when people who don't know anything about a topic run off on things they don't understand.
P.S. None of your "attacks" can target client-side frameworks, that's ridiculous because all of that code runs client-side.
1. nope.
2. Yup, JS is a client based system at it's core, in server-side js it treats the server as the client in the functionality, HOWEVER this code is usually open to external input like an angular backend that can be logged into externally to the server. Some of these features are built-in parts of various frameworks, however they can be secured but usually it takes a fair bit of knowledge or reprogramming the framework if you are able to. There are also the other more general security issues with a lot of packages in that you can usually hit them with overflow attacks and other things like that (port hammering used to be a fun way to take something down that was using a JS based backend).
2.1 There is also the package problem which you ignored, in that NodeJS gives the packages a really large attack vector if they are compromised (as they have been previously), this allows a package to not only poison that package's code, but other parts of your project and was a huge issue only last year ongoing from 2018. This had the potential to affect not only client-side code (by way of redirection and injection of malicious code), but also as a way to insert multiple backdoors very efficiently onto a server.
2.2 Maybe talk to some security people man. The whitehats often use these vectors in reports as they are the most common used by hackers, well besides just talking someone into giving you access that is.
Your post-script makes no sense, you are saying you cannot target client-side frameworks because they run client-side (i'll assume the last part was meant to be server side). Yet a lot of these frameworks have ways of interacting with them FROM the client. Once you can give the framework reason to think you are running server-side (spoofing et.al.) you can then start to get the server-side code. If that is locked down you can start hitting it on insecurities in the most often used packages, trying for an overflow issue or something similar, the best would be if at some point db credentials are sent or received by the framework and you can catch them, pretty rare to come across that nowadays though.
Wordpress is written in PHP, but makes extensive use of JS libraries.
Here's an older image of the folder containing the OS JS libraries: https://subscription.packtpub.com/book/application_development/9781787126800/9/ch09lvl1sec85/open-source-javascript-libraries-in-the-wordpress-core
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
