> I'm not saying with that example you should leave it the way I posted it, > where access is global. In fact I agree with you. The user and pwd should be > verified on a user basis for something so open as the example. But what I do > say, is that I do not recommend allowing http access to this script if it > will be accessible to the internet. Even SSL is not bullet proof, but > at least it's not plain text.
Salting a DES3 cipher makes a nearly impossible to crack cipher. Each encryption changes, so it's impossible (or shy thereof) to get any kind of redundancy out of the encrypted data. Sure, given enough time, data, and iron, any encryption can be cracked. I wouldn't say that SSL is not bullet proof. It's an extremely secure technology, provided the libraries that handle it aren't compromised or compromisable (refer to previous OpenSSL exploit). > > 'CLEAR-FILE DATA VOC' is exactly the reason it should be behind some kind > of encryption, or even better yet (DOS /c 'FORMAT C: | y') or (SH -c > 'rm -r'). I didn't mean to give anything other than a clear cut example, > but the example is like giving a hacker a back door to the command line, so > be safe with it. That's really all I can say. > MVWWW utilizes an indirect execution method, which also relies on server-side execution control. Is it hackable? Only if you have direct access to the spooler and/or the database account running the services. The best part is, you can split the two by a router and have your CGI client running outside of, and your spooler/DB inside of, the DMZ. I shy'd away from TCL direct access methods because of the openess of it. EASY integration isn't always the best. ASP and PHP are both known for being quite exploitable, so I've tried to stay away from them as well. This is *especially* true for developers who are not aware of the security situations each scripting environment creates. To each his own, though. > In most of my uses the user an pwd are defined behind the scenes because the > server is out to do a specific chore. Like in a POS E-Commerce site. You > don't allow your customers access to your database, but you do allow your > servers to retrieve information from the database. > This all depends on how the interface is designed and implemented. A properly designed web app and interface can directly touch the database with no worries. The integration framework determines how far outside the box you have to go, to be safe. I'll agree that a dead DB is the safest DB to monkey with. In this age of impatient e-commerce, live data is crucial to business and E-business. You have to access your lifelines at some point, though. Daily updates, to a web-specific DB, are becoming a thing of the past. Centralization and localization of web services, web data, and personnel is (oddly enough) becoming a key aspect in many current and new business models. How ironic is it that we can already do all that, and have been doing all that with MV? > > Vance > Glen http://picksource.com http://mvdevcentral.com ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
