Not able to save or edit themes in 9.2.0000

Scriptcase 9 Bugs
#1

Hi. I did my 9.1.0006 to 9.2.0000 conversion this week and it seemed to go well. But today I realized I am not able to do a simple or advanced edit of any themes.

When I edit (the first simpler edit) a theme and try to save I get:

the class XmlparserIniSchema of the module Xmlp arser was not found. | Script: /home/dev91cbhc/public_html/scriptcase91/devel/lib/php/functions.inc.php linha: 154

If I even try and click the advanced mode I get a different error - I am showing what I could copy from the console, as the spinner just spins and covers up the words on he screen:

VM167 sc_js_AppSchemaAdvanced_ea661decb83f73779a8c18d18f56ea5a.js:52 GET https://dev91.cbhc.systems/scriptcase91/devel/iface/app_schema.php?schema_name=sys__NM__cats_theme_1&opcao=edit 403 (Forbidden)

#2

Upgraded to 9.2.0001 on 7/31/2018 and I am still having the same issues.

#3

Hello,

Try to apply recursive permission 755 in your scriptcase folder.

Ej.: $sudo chmod -R 755 /home/dev91cbhc/public_html/scriptcase91

Thank you!

#4

It turned out it was not the permissions. It was being stopped by the server’s ModSecurity system. The URL inside scriptcase causes a ModSecurity critical alert:

            ModSecurity? rule.  
            ID  218530


            Request:    GET /scriptcase91/devel/iface/app_schema.php?schema_name=usr__NM__bluewoordtest2&opcao=edit
            Action Description:    Access denied with code 403 (phase 2).
            Justification:    Pattern match "(?i:\\b(?:m(?:s(?:ysaccessobjects|ysaces|ysobjects|ysqueries|ysrelationships|ysaccessstorage|ysaccessxml|ysmodules|ysmodules2|db)|aster\\.\\.sysdatabases|ysql\\.db)\\b|s(?:ys(?:\\.database_name|aux)\\b|chema(?:\\W*\\(|_name\\b)|qlite(_temp)?_master\\b) ..." at ARGS_NAMES:schema_name.

I solved this by adding a whitelist rule for my Scriptcase9.2 IDE install , for rule 218530

Note that I noticed that another scriptcase action causes a different ModSecurity issues - another critical one. After you do a normal scriptcase version upgrade, there is a screen that has a link to …/log/upd/… .log There is a folder full of logs. That trips up the ModSecurity rule ID 210730.

Anyone running on a server with ModSecurity may have these same issues.

Perhaps SC could change the URLs or parameter names being passed to avoid these? I am sure the template advanced edit is triggering the critical event because the ‘schema’ is in the URL. That normally indicates and attack of some kind.

Just thought I would share this :slight_smile:
Jamie

#5

Hi Jamie,

I am running into this same problem that you write about in this thread. I have been unable to figure out the solution and my ISP states that they can’t modify the rules in ModSecurity in CPanel. Would you be willing to share your whitelist fix me and the rest of the forum?

Thanks in advance,

Chip

#6

Hi,

Jamie you’re right, modsecurity is a real problem, i had the same problem on my dedicated server, i solved it as follows:

these are hits from modsecurity:

[IMG2=JSON]{“data-align”:“none”,“data-size”:“full”,“height”:“191”,“width”:“1631”,“src”:“https://i.imgur.com/WfUppbw.jpg”}[/IMG2]

[IMG2=JSON]{“data-align”:“none”,“data-size”:“full”,“height”:“157”,“width”:“1535”,“src”:“https://i.imgur.com/ALuG1wP.jpg”}[/IMG2]
[IMG2=JSON]{“data-align”:“none”,“data-size”:“full”,“height”:“199”,“width”:“1628”,“src”:“https://i.imgur.com/8XgAOy1.jpg”}[/IMG2]

I put the following in

/etc/apache2/conf.d/whitelist.conf

<LocationMatch "/scriptcase9/devel/iface/app_schema.php">
SecRuleRemoveById 980130
</LocationMatch>
<LocationMatch "/scriptcase9/devel/iface/app_schema.php">
SecRuleRemoveById 949110
</LocationMatch>
<LocationMatch "/scriptcase9/devel/iface/app_schema.php">
SecRuleRemoveById 942140
</LocationMatch>

Then

apachectl -t

and restart

/scripts/restartsrv_httpd

that is all!
Maybe someone else will help

[B]Whitelisting in ModSecurity

https://www.liquidweb.com/kb/whitelisting-in-modsec/[/B]