agreed, and the more obvious back door hacks like external prg/vcx, debug alterations, bindevent and so on easily available in desktop apps won't happen behind a web server unless leaving big holes open.

>And SQL injection is a risk with almost any language.
>
>>I am with you and Rick on the security of a vfp task behind a Win server and the lesser risk of vfp seen as a tempting target for hackers.
>>
>>That said, with the more dynamic way vfp operates there are many more temptations to leave backdoors in the vfp code, SQL injection being the most famous one other backend systems also have to be afraid of.
>>
>>But this has to be resolved at the code of the actual app ;-)))
>>
>>
>>
>>>Rick,
>>>
>>>Can't agree more with you
>>>
>>>Vulnerability on a West-Wind Web Connect (WC) running in COM mode behind IIS just sounds to me like science fiction, not only because hackers don't care, but for very pragmatic, provable reasons:
>>>
>>>(disclaimer: I'm deeply involved in FoxInCloud which is based on West-Wind Web Connect)
>>>
>>>1/ About security
>>>==============
>>>WC APP RUNS ENTIRELY BEHIND A WEB SERVER (IIS generally):
>>>- WC runs as a registered, 'legal' IIS extension, just like ... ASP, ASPx, PHP, ... either through ISAPI or as a .Net module
>>>- WC opens no extra IP port
>>>- WC complies with all the IIS and Windows security mechanisms (which may become a concern when installing a WC app on a recent flavor of Windows Server because of all the additional security mechanism added to each new version of IIS)
>>>- WC receives HTTP requests from IIS - no binary, magical, esoteric commands - just HTTP requests (plain text) that IIS has received from the HTTP client, generally a browser, and defers to WC.
>>>
>>>A WC APP IS JUST AS SECURE AS IIS AND WINDOWS
>>>
>>>2/ About VFP code execution
>>>======================
>>>WC is written: part in C# as a .net module (wc.dll), part in VFP
>>>
>>>The VFP code that WC and the hosted app execute depends on:
>>>- the c++ redistributable (msvc?71.dll) and the corresponding 32-bit Windows APIs
>>>- the Windows file system
>>>
>>>Unlike a VFP desktop application, a WC web application has no dependency on any other peripherals, eg:
>>>- no dependency on Graphic Display
>>>- no dependency on Printers
>>>- no dependency on Network protocols such as SMB(2)
>>>
>>>The risk that Microsoft breaks support on the C++ redistributable and the file system is null.
>>>
>>>3/ About the link between the WC extension to IIS (wc.dll similar to aspx.dll) and the VFP application
>>>============================================================================
>>>wc.dll and the WC/VFP application cooperate in 2 ways:
>>>- wc.dll transmits a HTTP request to the WC/VFP application
>>>- the WC/VFP application transmits a HTTP response back to wc.dll
>>>
>>>2 mechanisms can be used:
>>>- file polling: each party watches for a file written by the other party within a shared folder (preferred for development, possible for production)
>>>- COM: wc.dll instantiates a VFP object, sends HTTP request through a public method and gets the response through an asynchronous call-back (preferred for production: faster [no poll delay] and less maintenance [wc.dll starts WC instances automatically])
>>>
>>>The file polling mechanism only depends on the file system support discussed earlier
>>>
>>>COM support: in our Windows 2012 server, DCOMCNFG shows over 250 system COM classes; if Microsoft was to give up COM support, that is certainly not any time soon.
>>>
>>>
>>>>Al,
>>>>
>>>>West Wind Web Connection is still being actively developed and supported. So if there are vulnerabilities that show up, I'll get them fixed (if possible). In fact I just released a major update last week.
>>>>
>>>>I doubt that FoxPro or Web Connection specifically would be much of a target for hackers and given the long lifespan we've had since updates and the maturity of the Foxpro and Web Connection I think likelyhood of problems down the line are very small relatively to other things.
>>>>
>>>>Given that FoxPro has always been an edge product for Microsoft and never really needed anything in the way of support (or never had decent support to start with) loss of support doesn't strike me as a deal breaker. There might be plenty of other reasons - lack of developers, aging language and tool chain etc - but MS support is the least of the worries.
>>>>
>>>>The biggest worry with VFP IMHO will be if the Windows UI eventually makes VFP apps too quirky to be usable. So far it's been acceptable and one can work around it, but you never know what happens in the future. For server apps using Web Connection (or other Web tool) this is much less of an issue especially since you can control the platform. If you start on Windows 2012 R2 today you have at least 10 years before you have to retire those servers and before support runs out for those and it looks like Windows 2015 will extend that even further out.
>>>>
>>>>+++ Rick ---
>>>>
>>>>>>Hey all
>>>>>>
>>>>>>Currently, we have an outward facing web application written in VFP using the West Wind Web Connection and now that MS has given a hard deadline for ending support the higher ups are beginning to twist and shout.
>>>>>>
>>>>>>Are there any possible security risks that we should be aware of? We're looking at keeping this application going for the next 2 years as its replacement is brought up to speed?
>>>>>>
>>>>>>Any information/concerns appreciated
>>>>>
>>>>>You might want to ask Rick on the West Wind board about vulns specific to his product.
>>>>>
>>>>>I think you'll find the bigger concern for sites accessible from the public Internet is that they're using an up-to-date Windows OS and patched web server (e.g. IIS for West Wind) and protected with a router/firewall. I believe there is a BPA (Best Practices Analyzer) for various versions of IIS.