|
|
|
|
|
|
by gizzlon
4166 days ago
|
|
|
> Dynamicity usually refers to the fact that you can execute code that wasn't fully specified at runtime. As in eval()'ing code based on user input? That's pretty crazy, and I don't think (hope) a lot of real world security problems are caused by that! > Back to our problem: A dynamic website will typically take user input (e.g. the user name) and build a personalized view of the webpage for the user But this has little to do with the language, right? Now we're are talking about handling user input, which can be dangerous. The OP seems to get this confused as well, which is one of the reasons I claim he's not exactly an expert. A TLDR of the original article: "Handling user input can be dangerous, it's safer if you don't." But we already knew that... As far as eval()ing user input, well, just grep your code for eval(), no need to change language. |
|
|
His claim is that the mere fact that the language contains an "eval()" function (which is a feature of dynamic languages) inevitably increases the risk.
Quoting: Most of the computer languages used to write web applications such as DCMS systems contain a feature called eval, where programming instructions can be deliberately promoted from data to code at runtime. [...] but when it is left accessible to unskilled or malicious users, eval is a recipe for disaster.
> A TLDR of the original article: "Handling user input can be dangerous, it's safer if you don't." But we already knew that...
I would say:
1. DCMS are bad for public facing webserver because they process user inputs with a language that supports function as powerful as "eval".
2. DCMS are bad for public facing webserver because they run slow interpreted which is "1000 times" slower and enable DDOS