video regarding security

[Steve Wood]

I made a 2 minute video that I think every A5 web developer should watch. Not because I made it, but because it brings home a serious issue that all developers have to always be concerned with - security and data isolation.

The case is that I have (and still have) some function within one of my web applications that causes the Users table index to become out of sync with the database. I can't find it, and I think it may be due to the hardware configuration my client is using. But the point is, it becomes corrupt, and, even though only twice in six months, that had a disastrous effect on client confidence.

Because it was corrupt, and because of how I used to assign User table variables to session variables, I was getting the wrong record information from the Users table. The result was UserA was viewing UserB's confidential information.

The syntax I was using is (I want the CompanyID, which I use to filter records):

lookupc("F",session.__protected__ulink,"CompanyID","[PathAlias.ADB_Path]\web_users.dbf","ID")

The general syntax I now use is:

table.external_record_content_get("[PathAlias.ADB_Path]\web_users.dbf","CompanyID","","id=\""+session.__protected__ulink+"\"")

The first method uses the index which, if corrupt blows everything. The second does not use an index at all.

But there is more you can do to ensure safety and to provide good customer service (which is second only to security). That's what I try to show in the video. Here is the address: http://alphatogo.com/video/login_failsafe_demo.htm

I did not include the code in the video, but will send it to anyone who asks (I won't post it on the board). It includes a "double-checking" routine provided by Jerry that confirms I received back the record I expected.

[Bill Parker]

Re: video regarding security

The first method uses the index which, if corrupt blows everything. The second does not use an index at all.

I just did a test on a 500K record table, for some records at the end of the table. table.external_record_content_get(), lookupc(), and lookup() returned results immediately when filter used an indexed field. Result was delayed when a non-indexed field was used in filter. (In fact the table.external...() is still running as I write this.) So LQO is working when an index is available. Which means LQO probably will use a corrupt index as well.

So the testing for correct record is the best defense.

Bill.

[Steve Wood]

Re: video regarding security

Yes, when I originally posted, I thought table.external_... did not use index at all, but every function I tried, even just lookup(), used an index if available. You can't avoid having an index if your key field is flagged Unique or auto-increment, Alpha creats it for you. In my particular case, index.is_valid() returned True, even though the index was out of sync with the table.

It seems so heavy handed to double-check the Users table on each and every page refresh, but I can't see how you can avoid it since an Index can go bad at any time (although very rare and not without some reason).

I can't avoid using the index, and I can't assume it is not out-of-sync with the table and, in the web environment, I need to refresh my critical session variables on each page refresh. So what else are we supposed to do?

[Bill Parker]

Re: video regarding security

I had hoped/assumed that the single thread nature of the WAS would eliminate any index issues. Back in the A4 DOS days there were no index issues, but that was using the .ndx structure vs. .cdx.

Bill.