ID:181770
 
I understand that BYOND was not ever intended to face a software engineer when it comes to security.

I also understand that there are without question vulnerabilities in BYOND that allow exploitation.

My Question Is This:

How secure is BYOND really?
How vulnerable is it to exploitation?

I'm speaking in reference to actually creating standalone applications. (Yes, I know BYOND does not inherently allow for standalone functionality, but it is possible through methods mentioned in this thread: ID:717266 )

I honestly have no concept of how secure normal applications are to begin with anyway, so I kind-of need a reference point here.

For an example: Lets say there is a lighting company that handles installations of the big lights that are used at schools. They use a database software to store their information, things like device & part information, transaction histories, whatever.

Is that software even 'intended' to be secure? Or is it as vulnerable as anything else.

It is certain that if there is security, there is a way to break that security. The question is really how long does the person in question want to spend trying to get through said security. All I'm wondering is would BYOND be sufficient to be used in situations excluding things like banks and government shenanigans.

Another example for a situation I'm asking in reference to is something like a law firm's case files. These files are public record, and as such can be viewed by anyone assuming they take the time to request them. Would BYOND be sufficient to write software for indexing their files or things of that nature? (Backed by a MySQL database of course)
There are essentially several classes of security you want, depending largely on the data or process you intend to secure.

Banks are not too different from military applications, in so far as they require a degree of obfuscation across both the whole process, and the data resulting from this process. These classes of application happen to share a good number of other simiularities in non-functional requirements, which perhaps says a lot about society. This is the class of applications that deal with highly sensitive data. Patient records can also go into this class in the UK, with similar other requirements.

Then there are a class of applications that deal with personally identifiable data. This is actually a pretty big class, although mitigated fantastically by the user themselves. Generally speaking these systems can have an open process quite happily in a well implemented solution, however keep the data itself closed. You will often find that this class actually contains data that isn't very interesting to individuals, but more-so to companies for trending purposes. Very little actual design consideration needs to be paid to the non-functionality security requirements of this class of applications, and consequently isn't.

Then finally you have open systems. These may vary in their degree of openness, however the security in them ultimately pertains to permissions more-so than out and out exclusion. You don't want users being able to impersonate each other etc etc.

This doesn't answer you question. What answers your question however of "Is BYOND any more vulnerable than an independently implemented application?" is a review of the platforms. From the perspective of process the answer is no, for all but the first class of applications I highlighted. BYOND provides a mechanism to allow you to implement permissions for your users and hide data, and provided that your deployment environment is secure, and your programming is not at fault, it will do this well enough, just the same as a standalone application.

Frankly the lower two classes of software are not inherently designed with security in mind at each step, because to do so costs a fair bit of money, just like to develop multiple-point critical hardware redundancy in your deployment scenario. Generally speaking these systems are secured by virtue of good programming practices, and good deployment. BYOND undoubtedly has bugs around that will allow you to cunningly elevate your priveledges somewhwere along the line, but they are not important for the lower two classes provided they are not glaring. I don't know any, I don't think anyone else does currently, so they aren't glaring.

The big advantage that BYOND provides, is that your application is sandboxed. A C++ application (particularly a nice and complex Win32 one) has the "benefits" of being tied to Windows, and the remarkably flimsy security that goes with it. It's significantly easier to generate a buffer over/underflow issue in C++ than BYOND, and these are often the common cause of programmatic exploits in applications. BYOND allows you to deploy on Linux and FreeBSD, a definite plus if you intend to get more serious with both your deployment permissions and underlying OS security as a whole. WinAPI will not grant you this same luxury by itself. BYOND is a peashooter as far as programmer created security issues go, C++ is more like a Pancor Jackhammer. As far as data security goes though, they're the same pretty well.
In response to Stephen001
Stephen001 wrote:
... ... ... ...

Absolutely enlightening as always.

Thank you for the info.

Basically what I see it comes down to is when accessing a MySQL database remotely the login / password is going to be accessible from the computer that is doing the accessing. There is very little you can do to restrict this ultimately, and trying is pretty much a waste of energy.

That being the case, someone could create / delete any information they wanted from the database (that they had permission to) even if the BYOND program was not given the ability to do so.

The thing is though, that the same could easily be done with PHP and the like as well.

So really the security issues in this case go only so far as only allowing MySQL access to local addresses (can this be spoofed without controlling a local PC?) and keeping an eye on the local PCs.

Is my last paragraph a fair assumption there? Any other general protective measures that should be taken?
In response to AJX
A local DB works fine for that particular issue, assuming you'd secured the deployment environment. Your main issue is sanitising the SQL queries themselves.
In response to Stephen001
Stephen001 wrote:
A local DB works fine for that particular issue, assuming you'd secured the deployment environment. Your main issue is sanitising the SQL queries themselves.

Shared database across an office. :)
And by 'secured deployment environment' you mean keep the office clean of any security vulnerabilities and keep access to server computer restricted from anywhere but local connections?

And saniti<big>z<small>ing the SQL queries howso? Are you talking about me personally (being bad at SQL :( ) or in general? Slight elaboration here would be appreciated. :)
In response to AJX
http://en.wikipedia.org/wiki/SQL_injection

I'll be honest, I wouldn't use BYOND for wholly non-security reasons myself.
The answers to your questions are simple:

If you use or build a significantly complex system (BYOND is, and Windows is, and any gov't database system is), it is guaranteed to be insecure.

If you need a great degree of security, hire experts in the field who can teach you to use better tools more wisely, and do your own homework on computer security using publicly available books and research papers. The experts can't make things secure, but if they work hard they will keep you one step ahead of potential data thieves and other miscreants.

If you don't need a great degree of security, stop worrying about it.
In response to Stephen001
To be fair on the buffer overflow quip, many modern compilers implement at least basic buffer overflow protection. This doesn't apply to the broad range of applications still compiled under MSVC6 and the protection isn't perfect, but it's enough for most scenarios with a typically negligible performance impact.
In response to AJX
AJX wrote:
And saniti<big>z<small>ing

When dealing with international communities, remember that, say, the British spelling for words---such as "sanitise" or "colour"---is not necessarily the same as the US spelling. Oftentimes those silly folk toss out that beautiful z for an ugly s.

Obviously their spelling is in err, but what can we do? Not much, to be sure!
In response to Kuraudo
Kuraudo wrote:
AJX wrote:
And saniti<big>z<small>ing

When dealing with international communities, remember that, say, the British spelling for words---such as "sanitise" or "colour"---is not necessarily the same as the US spelling. Oftentimes those silly folk toss out that beautiful z for an ugly s.

Obviously their spelling is in err, but what can we do? Not much, to be sure!

Absolutely true. However being the arrogant american that I am, I am naturally correct. I also grasp at any chance I get to try and correct Stephen. Usually, however, I end up failing dramatically. Like you see here. It makes me sad. I'm going to stop typing super short pointless sentences now.
In response to AJX
It makes me much less keen on replying if I know that people will turn "being correct" into a contest to such a degree that they will be pedantic to the point of correcting regional differences. People should have the leeway to be wrong, so long as they learn the lessons brought forward by that and pass those lessons on. I don't enjoy how accurate my posts are being made a spectacle of, in jest or otherwise, simply because I've been correct in the past.
In response to Stephen001
Stephen001 wrote:
in jest or otherwise

Ouch. Apparently I misjudged our relationship a bit more than slightly.

Never meant to be offensive to you. As implied, my comments were meant to be humorous, though apparently I failed quite thoroughly at that.
In response to Stephen001
I have great fun tripping up people with words. A few times people who are being spelling or grammar Nazi's in games will call me out on words like "colour" and "centre". My favourite is when they correct "inane" to "insane". That always gets a laugh. =)