M2Raise.ml - PHP Platform! VERSION 1.0

[wildramen]

I request to close this Topic. The platform is going back to development stage.

[Computerfreek]

Looks pretty suspicious.
A nobody who releases a new homepage cms completely free which is strangely obfuscated by some weired "crypter".

Without offending you I'd bet $5 that it contains some backdoors or at least security flaws somewhere in there which nobody can find.

[K.A.K.A.S.H.I]

Hat bei mir ein Virus.

[wildramen]

Originally Posted by K.A.K.A.S.H.I

Hat bei mir ein Virus.

No, it's not a virus. Try something like virustotal.com, the result will show the truth. Also, it's just compiled and archived, so my PC is a clean environment.

Originally Posted by Computerfreek

Looks pretty suspicious.
A nobody who releases a new homepage cms completely free which is strangely obfuscated by some weired "crypter".

Without offending you I'd bet $5 that it contains some backdoors or at least security flaws somewhere in there which nobody can find.

Somebody told me that it's better to get off the obfuscate system and make it open source. Well, i guess it's a good idea, but all the inputs in the forms are escaped and the GET variables for pages are also escaped. I guess there are no backdoors.
The only thing i've missed is an IOSEC HTTP Security tool, but it will come in the next version. This is a real snap.

[Gl0bal]

Abgesehen davon das der Code "compliled" ist, wenn man das so nennen darf, hat das Ding mehrere Probleme die einem beim erstem Blick auffallen, auch wenn man von dem Virus absieht.
1. Es nutzt die alte Mysql Schnittstelle
2. Es hat keine Plugin Schnittstelle, wenn man schon versucht sein cms zu crypten, dann ist sowas unbedingt von Nöten
3. Es hat einen prozeduralen Programmierstil, wer heute noch ein größeres Stück Code so schreibt, macht irgendwas falsch.

Mein Fazit:
das Hen CMS von 2010 ist besser.

PS: Die PayPal-Integration kann auch nur jmd nutzen, der ein PayPal Geschäftskonto hat und ich denke das haben die wenigsten hier.

MfG

[.Ɓurly]

I won't use it. But because no one said it before: Thanks for releasing.

Kind Regards

[Gl0bal]

Originally Posted by Lord Metho

Ich frage mich, was daran falsch ist...? Könntest du mir die "decompiled2 geben? Damit ich's selber beurteilen kann, denn die Argumente, die du bringst, entsprechen nur denen, die man beim !HEN bringt, also wieso ist !HEN besser?

ich habe keine decompliled version.
Ich denke jeder der die objektorientierte Programierung versteht, der wird dir das bestätigen:
Code ist leichter wiederverwendbar, leichter wartbar... wtf warum schreibe ich das informier dich doch selber jede Quelle des Internets wird dir sagen, das oop in größeren Projekten heutzutage unabdingbar ist. Nen mir mal ein aktuelles Framework, was darauf verzichtet.
Ich bin mir nicht sicher, ob du das ernst meinst. Du nennst dich doch selber Php-Entwickler, da wirst du doch wohl das Konzept der objektorientierten Programmierung verstehen.

Das Hen! CMS ist sicher. Es ist vielleicht nicht schön, aber sicher, was ich bei diesem Ding nicht sagen kann.

Es ist OpenSource und dadurch erweiterbar, was hier nicht der Fall ist.

Das macht es für mich besser (Auch wenn es trotzdem nicht mehr zeitgemäß ist (siehe meinen Blog)).

[/exit]

Originally Posted by Lord Metho

OOP ist schon besser. Aber deswegen grade zu motzen ^^. Ich benutze eigentlich nur OOP, aber wem's nicht zusagt...

Was du zu OpenSource sagst, da kann ich dir zustimmen, aber wenn du selbst in PHP Programmierst weisst du das es von der Struktur her, in den beiden Schnittstellen zu mysql einfach fast keinen Unterschied macht. Wenn man der Sch* eine goldenen Krone gibt, bleibt's Sch* mit einer goldenen Krone. (<- Ich finde jedoch, PDO ist auch nicht die Lösung). Ich will's mir aber zuerst angucken, bevor ich wirklich urteile.

Das Gefühl sagt mir aber es ist ein "gemodetes" !HEN...

Wenn du OOP-Codest wüstest du das mysqli in Punkto "sicherheit" einen
enormen Schritt nach vorne gemacht hat, gegenüber mysql.
Und was bringt dir ein compiled CMS wenn du nichts daran verändern kannst?

[wildramen]

I've read all your suggestions and this short-talking time gave me some reasons why i should go back to an open-source code. Well, i understand the fact that people cannot trust each other, and that's fine because i realised the fact that i wouldn't use this if it would be coded. The only reason why i obfuscated it ( not compiled, it's a misunderstanding here for me ) it's because any form of profit should be protected. I should go back and edit all the versions and stuff like this, so this post will be hardly edited and hopefully, i will expand my project.
To be honest, it's hard to understand the choices of another CMS - every website has a great support for coding, good community to talk about, but the hard work and every night lost doing this project.
That's fine, these suggestions are hardly the best i can get yet from experienced people who does programming as well.

So, back to work, i should get some stuff to fix, like this thread, maybe i will launch a github repository and it will be opened for every mind around the globe.
Thanks a lot! ^^ Best regards.

[Bently.]

Empfehlenswert wäre ebenso die Datenbank-Verbindungen etc. mit PDO zu machen

[Mashkin]

PHP Code:

// inc/func.core.php
// ESCAPE A STRING BY REPLACING MALICIOUS CHARACTERS
function escapeString($var)
{
    return str_replace(array('//', '\\', "\0", "\n", "\r", "'", '"', '\x1a', "<script>", "</script>",
        "<script", ";","!", "#", "%", "&", "DROP", "INSERT", "ALTER", "SHUTDOWN", "UPDATE", "update",
        "drop", "insert", "alter", "shutdown", "--", "\'\'"), "", $var);
}

// code/admin_connect.php
$login = escapeString($_POST['login']);

$query = mysql_query("SELECT * FROM ".ACCOUNT.".account WHERE login = '".$login."' AND password = PASSWORD('".$password."') AND web_admin > 0"); 


Notice the lack of secure input escaping, which will easily allow for an SQL injection vulnerability.
Even the age-old mysql plugin has a proper escaping method, .
While in theory, your escaping method does the same thing (plus a bit more), it does not take into account certain implicit conversions that MySQL may do, most prominently to convert unicode quotation marks to local encoding quotation marks (read on and in OWASP presentation).
MySQL's mysql_real_escape_string() knows how a string might be affected be implicit conversion, your filter doesn't.

Even Hennink's code used proper escaping in most places, so it isn't wrong to assume his code is safer in this instance.

Replacing all occurences of INSERT, UPDATE, etc.and insert, update, etc. is pointless, because InSeRt works just the same (SQL keywords are case-insensitive) and will slip through your filter.

That's for SQL injection. There are more flaws to your filter/escaping method regarding XSS (cross-site-scripting). PHP has native escaping methods for user-provided content embedded in HTML, e.g. . Read the .

I won't discuss procedural style and won't rage about using oldschool mysql plugin, I won't even talk about SQL prepared statements. Find some cheat sheets and recommendations, e.g. on OWASP, yourself.

[wildramen]

Originally Posted by Mashkin

PHP Code:

// inc/func.core.php
// ESCAPE A STRING BY REPLACING MALICIOUS CHARACTERS
function escapeString($var)
{
    return str_replace(array('//', '\\', "\0", "\n", "\r", "'", '"', '\x1a', "<script>", "</script>",
        "<script", ";","!", "#", "%", "&", "DROP", "INSERT", "ALTER", "SHUTDOWN", "UPDATE", "update",
        "drop", "insert", "alter", "shutdown", "--", "\'\'"), "", $var);
}

// code/admin_connect.php
$login = escapeString($_POST['login']);

$query = mysql_query("SELECT * FROM ".ACCOUNT.".account WHERE login = '".$login."' AND password = PASSWORD('".$password."') AND web_admin > 0"); 


Notice the lack of secure input escaping, which will easily allow for an SQL injection vulnerability.
Even the age-old mysql plugin has a proper escaping method, mysql_real_escape_string().
While in theory, your escaping method does the same thing (plus a bit more), it does not take into account certain implicit conversions that MySQL may do, most prominently to convert unicode quotation marks to local encoding quotation marks (read on and in OWASP presentation).
MySQL's mysql_real_escape_string() knows how a string might be affected be implicit conversion, your filter doesn't.

Even Hennink's code used proper escaping in most places, so it isn't wrong to assume his code is safer in this instance.

Replacing all occurences of INSERT, UPDATE, etc. and insert, update, etc.is pointless, because InSeRt works just the same (SQL keywords are case-insensitive) and will slip through your filter.


I won't rage on procedural style and using oldschool mysql plugin, I won't even talk about SQL prepared statements. Find some cheat sheets and recommendations, e.g. on OWASP, yourself.

Will it be better if i would change the actual code with this?

function escapeString($var)
{
    return mysql_real_escape_string(str_replace(array('//', '\\', "\0", "\n", "\r", "'", '"', '\x1a', "<script>", "</script>", "<script", ";","!", "#", "%", "&", "DROP", "INSERT", "ALTER", "SHUTDOWN", "UPDATE", "update", "drop", "insert", "alter", "shutdown", "--", "\'\'"), "", $var));
}

[wildramen]

Originally Posted by Lord Metho

No, you can use intern functions from PHP like strip_tag() htmlentities() htmlspecialchars() fgetss() or the opinion like htmlentities_decode() ...for a connexion with PDO = PDO::quote() <- A public function. To use it set a namespace.... You can also use prepared Arguments. But never use user-defined functions. There is also filter_var(_input) for Requests.

So the fact that i wanted to escape strings using a str_replace() is a bad idea. Then i should read more about this type of security before i'm in. It's pretty complicated and i am not very familiarised with the public namespaces and public functions. Thanks a lot! You rock!

[iKyroja :>]

i don't recommend to use it!
mysql_ and may some other functions are outdated.
I don't know why people still code prozedural in projects like this.
You realy should take a look at OOP.

[Mashkin]

Originally Posted by wildramen

So the fact that i wanted to escape strings using a str_replace() is a bad idea. Then i should read more about this type of security before i'm in. It's pretty complicated and i am not very familiarised with the public namespaces and public functions. Thanks a lot! You rock!

Escaping and input sanitaziation are complex topics.

Why do you want to escape data?
Data is usually inserted into other data that might have a meaning (e.g. an SQL query, JavaScript code or HTML markup) and a syntax. When data is inserted into this syntax, it might break or alter its meaning.

In HTML and JS (and CSS as well), this can just break your web page's layout, or lead to cross-site scripting (XSS) vulnerabilities because someone has control over what happens in a page visitor's browser when she loads your page.

Think about guestbook system, where the data one user enters will be displayed to other users:

<p class="comment"></p>

Now an attacker adds a comment including HTML markup and gains control over other users' browsers:

<p class="comment"><script>alert('XSS')</script></p>

The same can happen with SQL when a user's input string can "escape" the string delimiters (quotation marks) and manipulate the instructions of the query.

Every scenario (HTML, JS, SQL etc.) has different requirements that escaping must meet to be secure.
For SQL quotation marks are dangerous, for HTML content brackets ('<' and '>') are dangerous, and for HTML attributes there is a whole pallette of possibly dangerous literals.

The conclusion is that a good escaping method needs to know the exact context where the escaped data will be injected (e.g. the SQL quotation mark conversion I mentioned in my earlier post).
This is the reason why there are individual escaping methods for different use cases (e.g. htmlspecialchars() for HTML and mysql_real_escape_string() for MySQL strings).


So start using different escaping methods for different use cases, and use the methods that already exist and are known/proven/expected to be secure.