| This 94 message thread spans 4 pages: < < 94 ( 1 2 3  ) || |
|WordPress isn't secure.|
| 12:59 pm on Oct 30, 2013 (gmt 0)|
I'm serious. I've heard many people say/write that WordPress is a security nightmare - that it has security holes. This may be true but I haven't found it to be so and I have yet to see anyone offer proof of it. On the other hand, the WordPress core development team has been working hard and the general message I get from the WordPress community is that WordPress is secure. What to believe?
I believe that a hacker might be able to find their way into a WordPress install but I believe WP is no less secure than a Drupal or Joomla or any CMS script out there. If you have proof to the contrary, I'd like to know about it. Please don't post hearsay and suppositions. If you know of a security issue, let's have it so we can examine it and discuss it and see if there's a solution or work around.
Please keep the tone professional.
| 4:06 am on Nov 27, 2013 (gmt 0)|
|open architecture offered few constraints on developers, the opportunity for security holes resulting from apps was significant. |
In general, more open platforms are not more vulnerable.
|Similarly, the problem with any framework like Symfony is that you can't expose Symfony to a developer without exposing all of PHP |
There is a big "but". Take a look at my Django example code above. It returns a "queryset": this can either be modified, or can act as an iterator that returns objects.
You could do the same thing by directly using SQL, but that is more difficult because you would need to then create the objects yourself etc.
If you make the easy way the safe way, then developers only resort to the insecure way (e.g. building SQL as strings) if they really have to. Developers retain the power to shoot ourselves in the foot, but lack the incentive to take the risk. Assuming that we are primarily protecting against developer error rather than malice, this works extremely well.
| 5:07 am on Nov 27, 2013 (gmt 0)|
>>if they really have to.
Or if they don't know the framework that well.
>>more open platforms are not more vulnerable
No? If you expose low-level functions, then you tend to expose a system without, say, basic sanity checks so a developer has to know what he's doing to avoid... I don't know... buffer overflows. I vaguely remember my assembly language programming course, but it was real easy to take a machine down with code error in assembly language. When you open up your system to expose low level functions to programmers, you place a greater burden on the programmer to keep things straight.
And so it is with PHP-based templating system in Wordpress and Drupal - you're exposing a lower level of functionality than a themer/designer should need to see generally speaking.
| 5:35 am on Nov 27, 2013 (gmt 0)|
|Or if they don't know the framework that well. |
In the case of Django, its hard to imagine someone knowing the framework well enough to know how to execute a raw SQL query and use the results from within the framework without knowing how to do it the easy (and safe) way.
It is possible that someone who knows the underlying database connector might only use the routing and a few other bits from the framework, but is very unlikely as they would lose the most of the benefits of the framework.
|When you open up your system to expose low level functions to programmers, you place a greater burden on the programmer to keep things straight |
Yes and no. Potentially so, but there are a lot of other factors. Is Windows more open than any comparable OS that is more secure? Also things like buffer overflows are a different issue from a low level API.
| 5:53 am on Nov 27, 2013 (gmt 0)|
let me put this another way. Which is safer:
1) If you forget to sanitise you create a vulnerability to SQL injection.
2) If you dig into the documentation and do a lot of extra work you can use low level APIs and then for get to sanitise you create a vulnerability.
A system that does not even have the safe high level API has to be less secure than one that does.
| This 94 message thread spans 4 pages: < < 94 ( 1 2 3  ) |