|
Answer» For awhile now, I've been trying to learn computer programming, and it just isn't working. Concepts such as multitheading, and security are giving me a hard time to really understand.
I do however like database, and good with SQL queries and database modelling. My question is, if I were to switch my focus to SQL and Database admin type of work, do I have to worry about security, i.e SQL injection, hashing a table, etc... or is that at the programmer level? i.e the programmer has to worry about how to access the database, correct? Using parameterized queries, all my job is, is to create the database using whatever software my job requires, Oracle, SQL Server, etc...Its the responsibility of all to protect security.
The database admin would set the data types as WELL as would have to stay on top of keeping the database ( MySQL in my case ) patched as up to date as possible without hopefully breaking legacy support. Constantly keeping an eye out for exploits and patching when they are discovered and patch available. They also would limit the access to the database to only those who need access to it so its not wide open to all.
The programmer is involved in setting limits in how the connection is established, and limits set on information passed to avoid an overflow condition.
*I'm speaking from my EXPERIENCE as a Systems Admin in which I had to do all 3 roles + everything else. Fortunately the database was accessible in house only and was not on the WWW for hackers to hit. For people needing to access it remotely we had them connecting through Remote Desktop sessions initially, and then upgraded to Citrix which allowed the database transactions to remain in house and only keystrokes and mouse activity and video images to be passed across so there was no direct injection methods from the end users or WWW.
I would have been very nervous having my database server on the DMZ. So I went this route above instead to have the protection of the security of RDP or Citrix as a line of defense to avoid hackers gaining direct access to the database through an online web interface. Many thanks for your answer, one question though, when it comes to SQL injection, it would be up to the DBA to ensure that it doesn't happen, or is that programmer level? Both ....
Some patches fix exploits that correct for injection attacks. So you as a DBA would likely patch say version 5.6 to 5.7 upgrading the software thats handling your database such as MySQL software update etc. *It gets tricky when you have legacy calls to the database such as calls created under 5.0 which may not be supported under 5.7 but may have worked under 5.6. The programmer then has to work with the DBA to use a newer method vs legacy method. So a patch/upgrade can break things that are legacy.
Programmers are the first line of defense from the outside by their code testing the data to be passed to the database before the database accepts the data. If the information to be passed to the database does not comply with the rule set, then their code would specify that there was a problem and the information not passed to the database.
http://www.enterprisenetworkingplanet.com/netsecur/article.php/3866756/10-Ways-to-Prevent-or-Mitigate-SQL-Injection-Attacks.htm
Quote Trust no-one: Assume all user-submitted data is evil and validate and sanitize everything.
Don't use dynamic SQL when it can be avoided: used prepared statements, parameterized queries or stored PROCEDURES instead whenever possible.
Update and patch: vulnerabilities in applications and databases that hackers can exploit using SQL injection are regularly discovered, so it's vital to apply patches and updates as soon as practical.
Firewall: Consider a web application firewall (WAF) – either software or appliance based – to help filter out malicious data. Good ones will have a comprehensive set of default rules, and make it easy to add new ones whenever necessary. A WAF can be particularly useful to provide some security protection against a PARTICULAR new vulnerability before a patch is available.
Reduce your attack surface: Get rid of any database functionality that you don't need to prevent a hacker taking advantage of it. For example, the xp_cmdshell extended stored procedure in MS SQL spawns a Windows command shell and passes in a STRING for execution, which could be very useful indeed for a hacker. The Windows process spawned by xp_cmdshell has the same security privileges as the SQL Server service account.
Use appropriate privileges: don't connect to your database using an account with admin-level privileges unless there is some compelling reason to do so. Using a limited access account is far safer, and can limit what a hacker is able to do.
Keep your secrets secret: Assume that your application is not secure and act accordingly by encrypting or hashing passwords and other confidential data including connection strings.
Don't divulge more information than you need to: hackers can learn a great deal about database architecture from error messages, so ensure that they display minimal information. Use the "RemoteOnly" customErrors mode (or equivalent) to display verbose error messages on the local machine while ensuring that an external hacker gets nothing more than the fact that his actions resulted in an unhandled error.
Don't forget the basics: Change the passwords of application accounts into the database regularly. This is common sense, but in practice these passwords often stay unchanged for months or even years.
Buy better software: Make code writers responsible for checking the code and for fixing security flaws in custom applications before the software is delivered. SANS suggests you incorporate terms from this sample contract into your agreement with any software vendor. Depending on the company, would it be possible to find a job where you do data modeling/write queries, but aren't responsible for security, and higher up admin tasks? I'm not opposed to doing the higher up admin tasks, if the company took the time to show me, and explain what/why of doing it.
The reason why I ask is, I'm sort of in a situation where my college didn't do a good job of teaching the high-up topics (threading, generics, security, and many others), so I'm sort of learning what I can on my own, and decided to switch my focus to database instead of OOP. I like writing SQL queries/database modeling, so if I can get a job doing that, it would be great. SQL injection is more at the application level but IMO anyone working in IT should properly understand the security. For example, one large job of administering databases is ensuring that the system is properly patched to protect against security flaws, it is important to understand what these vulnerabilities involve. You would also be required to understand how a database works underneath the surface so you can properly administer and optimise it - I doubt you'll get a job just writing queries.When you say application level, you mean the software that will access and query the database, correct? If you can find a company that has databases that are not exposed to the WWW, all in house database use only. That would work for you well.
Most companies that are hiring are looking for people who can do all + 3 to 5 years working experience. I was fortunate that my first IT job I passed the interview so well that they hired me fresh out of college. But the better paying jobs out there were requiring 3 to 5 years + a portfolio with examples of work related to the position as well as references in the field.
The hardest part is trying to find the foot in the door position to get your 3 to 5 years. From then on if you have the skills, degree, and a good track record with your prior employer in that field, your golden.
Hopefully your college has a program worked out with employers in your area for internship or work study experience. I got my IT job before completing my degree and my college did have the work study. The cool thing is that I was able to work this same job I already got in IT which fulfilled my IT work experience study. At first the college director wanted me to go elsewhere vs my current job but there was no way I was going to be able to work 40 hrs a week in the job I already had in IT and then college + time to work for another employer in IT as well. Im glad that he saw that it made no difference whether it was a job I had already or not and I wasnt forced into 70 or 80 hrs a week with schedule conflict between 2 jobs + have time for college and assignments & study.
A hospital might have the work along your lines. They generally have intro IT positions for a help desk as a foot in the door and then once you have the job there you can bypass the 3 to 5 year requirement for the DBA work sometimes.
|
