MZTools Quality Review (1 Viewer)

Guus2005

AWF VIP
Local time
Tomorrow, 00:37
Joined
Jun 26, 2007
Messages
2,645
I am using MZTools for quite some time now and i recently started to use the Quality Review.

1602179512207.png


If you run it the result will look something like this:
1602179445538.png


You can add your own rules. I added the one that optional parameters must have a default value.

Now i am looking for a way to detect im/proper use of the kill command and other potential malicious commands.

First question: besides the obvious 'kill' command are there other commands that are potentially malicious?
Second question: if you use the Quality Review in MZTools, what are other rules to improve the overall quality of the code?

Thanks for your time!
 

Attachments

  • QualityReviewAdminOptions.xml.txt
    39 KB · Views: 110
Last edited:

isladogs

MVP / VIP
Local time
Today, 23:37
Joined
Jan 14, 2017
Messages
18,209
Thanks. I have barely scraped the surface of what MZ Tools 8.0 can do and have never used that feature

SQL Injection is the obvious example of malicious 'code.'
But code can easily be written to delete all local or linked objects. That can of course be done externally
 

Guus2005

AWF VIP
Local time
Tomorrow, 00:37
Joined
Jun 26, 2007
Messages
2,645
SQL Injection. First that comes to mind:
1602179821787.png

With regular expressions you can do almost anything. You can use regular expressions in a rule. So i'll look into that.
Any object with the method .delete or .remove can be questionable. Perhaps i can make a rule to detect those too.

Thanks Colin!
 

isladogs

MVP / VIP
Local time
Today, 23:37
Joined
Jan 14, 2017
Messages
18,209
Ah yes. That cartoon is regularly used whenever sql injection comes up.
My final comment about (most) malicious code being run externally will of course defeat any checks you can run using MZ Tools
 

Guus2005

AWF VIP
Local time
Tomorrow, 00:37
Joined
Jun 26, 2007
Messages
2,645
About to add a new rule:
Events must always have errorhandling.

Events are the last line of defense. If an unhandled error occured it bubbles up to the triggered event.
If it is not handled it generates a runtime error which is shown to the user and most likely the application crashes.
So it is good practise to always put errorhandling in events.

ToDo in MZTools:
Search for methodname with an underscore in it and search for ^[^'\n\r]*On Error Goto

I'll post the result here when i'm done.

{edit}
I had a methodname with an underscore in it. So instead of looking for an underscore i have added all possible event names....
All 61 of them and i am not even sure i missed one...
 

Users who are viewing this thread

Top Bottom