Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I've started reading a book on PHP security (but it's really all theoretical not so much practical) and have it in my plan to read Chris Shiflett's and Schenider's blogs, but does anyone know of a formal course that I can attend or even get a certificate that proves I know how to write secure PHP code?
Edit: I got a lot of answers, some of which don't answer my question. So I'm quoting ircmaxell's comment because it really hits the point.
While I agree with the cert not
mattering (and that finding
vulnerabilities is the best way to
learn), I'm not sure that answers the
question. How should one go from not
knowing anything about security to the
point where they can do audits to be
able to find vulnerabilities
What I want to add though is that while I agree that experience is more important that certification, certification is not unimportant. It's a quick proof that I know more than the high school hobbyist programmer from India who's charging $30 for a full project.
http://www.zend.com/services/certification/ is a good one.
Before you take that exam you might want to have a look at:
httpOnly Cookies
cross-site request forgeries
OWASP development guide
SQL injection
rules for processing credit cards
SSL/HTTPS
cross site scripting (XSS)
Cross-site request forgery
The Google Browser Security Handbook
The Web Application Hacker's Handbook
Writing secure code spans more than just PHP: good code, proper code is language agnostic. While there are nuances in each language, there are a base set of principals to learn that are transferable no matter what you write in. It's best to learn those core values and then learn about the specifics of the language. Basic knowledge of cryptography, good database design, proper memory management, and operating system principals will give you more insight to security than just being certified in PHP security.
When it comes right down to the point, writing secure code should be a part of any programmer's skill set.
http://www.zend.com/services/certification/
I highly recommend Chris Shiflett's book. I think it should be required reading for all web developers, not just PHP dev's, as the principles, attacks and defenses outlined are applicable to all web languages. It's also a quick read but would give you a firm grounding in web app security IMHO, negating the need for a course. The chapter on security in the Zend Certified Engineer study guide is also good but covers the same ground as Shiflett's book.
There was the OWASP Certification Project, but from what I can tell it's not active anymore (although some of the content linked still appears to be active).
While not PHP specific, there's also the GIAC Certification. It's targeted towards general security as opposed to language specific techniques (from what I can gather anyway)...
There's also the Software Security Institute... I have no background with them, so I can't really vouch, but it appears to have what you're looking at.
Edit: After some reflection:
Honestly, I don't see the point in certificates. If you want to attend training, great! But all that a certificate does is prove you were able to pass a test. It doesn't say anything about what you know or your capabilities... Get real world experience, that's worth more than any certificate any day of the week. Get involved with open source projects (especially from the security front, a lot need help there in my experience). Get involved with OWASP. Gain some real world experience, attend conferences and user groups to continue learning. It'll be worth 10 times as much as the certificate...
Get a CVE number for a PHP project. If you can't find vulnerabilities in PHP code is what matters, having a certification doesn't mean a damn thing.
In order to understand how code can be insecure I suggest Installing Damn Vulnerable WebApp. You should also look at real world vulnerabilities such as the ones found on The Whitebox. The blog and shop where PHP/MySQL projects that where abandoned because they are so insecure. The challenges are difficult security systems found in the wild, however they too are very insecure. For some offensive PHP security reading I suggest A Study In Scarlet.
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
If I write a login system for a client who later gets hacked can I or my company be held accountable for whatever damages they claim?
Excuse me if this has been asked already. I did a search and found no relavant answers.
I recommend that you consult an attorney for this kind of a legal question. This is a technical forum and not a place for legal advice.
The software warranty and the courts is a murky area. It really would depend on what warranties you provide. Typically with software there is an explicit denial of any warranty and that the software is a best effort however in the US anyone can sue anyone else for almost anything. Just trying to defend a suit can be financially devastating which is why housing contractors have a tendency to have multiple incorporated companies which carry the liability for homes built and insulate the contractors personal assets from any suits.
You do not say what your industry is. Different industries will have different standards. For instance in point of sale there are the PCI standards from VISA, etc. on security standards for card account information.
Depending on the industry and the kind of security breach, yes you could be liable.
You really should get the services of a security specialist and a lawyer in your software target industry to discuss this and other legal questions.
The main point to remember is that when there is a breach especially one with financial repercussions, more than likely your customers will look for someone to blame. So you really want to have something in writing that indicates who is responsible for any liability due to a breach. And as part of that there probably should be some description of what would be considered minimal acceptable security practices on the part of the people using the software.
That said a minimal set of necessary practices that you should follow would be something along the lines of the following. I make no claim these are anywhere complete as I am not well versed in computer security.
Reduce privileges and what can be done as much as possible. This hopefully will reduce the amount of damage that may arise when someone breaches the system.
Always assume that input may be tainted so watch out for standard intrusion practices such as SQL Injection or URL modification in the case of REST or other unexpected modifications to input data.
Never assume that just because something is hidden that it will not be found and exploited.
Log everything possible so that when a breach happens, the forensic team will have the data they will need for an investigation.
Passwords are a fairly poor authentication mechanism so you want to beef them up as much as possible. So password aging is important to force passwords to be changed. Password difficulty checks should be used so as to encourage more complicated passwords that will vary from change to change. Passwords should never be maintained in clear text nor should passwords be transmitted in clear text. Encryption is your friend and helpmate.
Biometric information can make for a better authentication mechanism however some people may have features that do not work well with some types of biometric systems such as people whose fingerprints do not work well. Some type of unique device may also be used such as an authentication code generator that is synchronized to a central device or perhaps a central device which sends an authentication code via a text message to your phone when you attempt to log in.
Using the system probably should require a password to be re-entered at the time of some sensitive action especially with systems which may be accessed from a public terminal.
Make sure that it is easy for someone to log out so that they will be more likely to do so as part of closing out a session.
Make it easy for users to be disabled by a supervisor and provide a way to make it easy for a supervisor to generate a report of who has access to what, when have they used their access, and what did they do when they had access.
Borrow a page from Gmail and other e-mail systems to notify the user whose account it is as well as a manager or supervisor via e-mail any access that seems unusual or of a sensitive nature. Also notify via e-mail if any user account type changes are made such as password change along with logging this type of activity.
We all know it is nearly impossible to produce a large website without one or two flaws. As such I've written a small monitor that checks Apache access logs for potential SQL injection attacks (amongst other things), and it's working very well. I get an alert whenever someone attempts an attack, and I've had so few false positives that the default action is now to dump them into an iptables drop list. It's even helped me identify a few (non-security) bugs and remove them.
Here's my rules (case insensitive):
PathInjection = \./\.\./(bin|boot|data|dev|etc|home|lib|lib64|media|mnt|opt|proc|root|sbin|selinux|srv|sys|tmp|usr|var)/
Havij = 0x31303235343830303536
r3dm0v3 = 0x7233646D3076335F68766A5F696E6A656374696F6E
LogicBypass = '.*?(\bor|\band|\bxor|\|\||\&\&).*?--
UnionSelect = union[^a-z-_]+((all|distinct)[^a-z-_]+)?select[^a-z-_]
What I'd like to know is, how would you bypass these checks and still produce a valid injection? Can you think of a way to improve them without introducing false positives?
A few notes:
Case sensitivity is switched off.
I'm using MySQL.
The Havij and r3dm0v3 entries are used as a catch-all to prevent use of those automation tools.
I'm checking both raw and urldecoded strings.
I'm not looking for answers like "make more secure code instead".
I'm not looking for a different way to do this, just a way to improve my current logic.
EDIT:
Ok, so people seem to have misunderstood my intent. That's probably my fault, since I didn't fully explain. This is being requested as a tacked-on feature to a monitoring product, and is designed to offer minimal security monitoring. As part of our dialog with the client and our documentation, we're emphasising that this is not a catch-all, nor is it a replacement for proper security infrastructure (e.g. an IDS and firewall). It's simply an informational service to help provide basic threat detection and produce statistics about the number of potential attacks. I'm not trying to write an IDS or firewall. If it were up to me, I'd leave the feature out and tell them to go install a full suite of security infrastructure with its own monitoring systems, but this isn't my call. The current situation is that I've been testing the system on my own site. Right now, I'm just looking for a way to improve the regex strings to make this more effective. Hopefully this clears things up a little.
Edit again, in June 2021.
I posted this question back in 2011. Back when I wrote it I was a junior developer with an interest in security but lacking experience. Since then I've switched careers to security, worked as a pentester for 5 years, and a security researcher for another two. I'm also one of the top reputation users on Security StackExchange.
The answers given here are mostly correct - there's far more value in deploying something like ModSecurity with appropriate rules, since they've already done the work. A tacked on homebrew solution is not going to compare to a project with almost two decades of maturity.
The one major caveat, though, is that I was not making the decisions. Junior developers usually have neither the privilege nor latitude to veto product decisions made by management, especially those made at the request of a customer. One can certainly explain why an idea is bad, and provide supporting material, but that often doesn't translate into changed decisions. Being able to refuse a task from your employer without consequence is an unusual privilege - the concept is a complete fantasy in the context of most employment.
My advice for folks who respond to these types of question is this: explain why it is ill-advised, but be sympathetic and helpful to those who are in a difficult position. Actually answer the question, wherever possible, so that a best-effort solution can be implemented if all else fails. In the context of security features, it's also worth considering that if the alternative is no protection or detection at all - even if that alternative is artificially being imposed by external actors - a weak capability is almost always better than no capability at all.
I don't remember what I ended up implementing for this. It was so long ago. But if you're here now, looking for answers, I recommend using ModSecurity. They now have connectors for Apache, nginx, and IIS, so you can install it on any of those web servers. If changing the server configuration is problematic, you could instead run nginx as a reverse proxy with ModSecurity enabled, so that users hit the nginx server and it proxies the requests to your actual web server. This can also be done with Apache instead.
If you're looking for a more programmatic approach, ModSecurity has language bindings for C, C++, and Python. The ModSecurity API can also be consumed via any language that has interoperability support for C APIs (e.g. P/Invoke in .NET, or JNI in Java).
ModSecurity works on rules. One of the best free rule sets out there is OWASP Core Rule Set (CRS). The rules are significantly more powerful than simple regex patterns. This makes them very effective, but it also means that you probably shouldn't try to build your own ModSecurity-like internal feature that consumes the rules, because you'd need to put in a ton of work to support all the necessary features.
If you need to parse ModSecurity logs into a format that can be automated upon, take a look at ModSecurity Log Utilities.
Hopefull this info is of use to someone in future.
You're talking about writing an IDS. Unless your product is an IDS, just get and install one. Snort is well-known and has a free version.
I'm not looking for a different way to do this, just a way to improve my current logic.
Sometimes when it comes to security, the wrong approach simply is. How would I mess with your current logic? Unicode or hex encoding.
Here is a nice example of IT threat detection using deep-neural-network vector embedding and a similarity search engine.
Can you think of a way to improve them without introducing false positives?
I wouldn't think of improving this silly approach at all. I'd rather improve the site security itself.
We all know it is nearly impossible to produce a large website without one or two flaws.
I disagree with that. At least for SQL injections. Injections are quite silly thing and protection is not a big deal.
sql injection is top rated web Application attack these days. There are many insecure code over the net and also there are several ways to protect application from sql injection attacks. sql injection can occur when an application uses input to construct dynamic sql statements or when it uses stored procedures to connect to the database. Methods of sql injection exploitation are classified according to the DBMS type and exploitation conditions Vulnerable request can implement Insert, update, delete. It is possible to inject sql code into any part of sql request Blind sql injection Features of sql implementations used in various dbms. Successful sql injection attacks enable attackers to execute commands in an application's database and also take over the server.
my recommendation:
Basically, make sure your web server is up-to-date with latest security fixes/patches.
Make sure you have filter every user input and output as proper encoding like UTF-8.
Read the full testing guide: https://www.owasp.org/images/8/89/OWASP_Testing_Guide_V3.pdf
try tom imlement web application scanner , check this link http://trac.ush.it/ush/wiki/SecurityTools
I do ex. watchfile now IBM aapscan tools http://www-01.ibm.com/software/rational/offerings/websecurity/ to scan all my web application
check google more how to protect against sql injection
Microsft http://msdn.microsoft.com/en-us/library/ms998271.aspx
http://www.sans.org/ "sql injection"
WASC: http://projects.webappsec.org/SQL-Injection
OWASP: http://www.owasp.org/index.php/SQL_Injection
CodeProject http://www.codeproject.com/KB/database/SqlInjectionAttacks.aspx
What security considerations should I/do I have to take into account if I decide to make a professional website(HTML,CSS,JavaScript,PHP,etc.). For example, when having a database, one should think about hackers who want to hack the website by SQL-injection. But there are many other examples. What I would like to know is a list of things(security) a webmaster must consider/take into account. Also maybe some things that are recommended, but not a must. A short explanation about each topic is much appreciated, but you don't have to. Thanks in advance.
btw. I'm not sure about the tags. Please add/modify if you know better.
The best resource for securing web applications is the OWASP Top 10: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
I suggest you read through each of these top 10 security risks and ensure you understand three things:
What the risk is
How it is exploited
How to protect against it in you language of choice
I just read this article about piggy backing in PHP.
I googled it but not so much information there.
Can anyone tell me more details how to prevent this kind of attack, what kind of code practices are vulnable and what we should do?
Thanks in advance.
That article seems to refer to a vulnerable web application, not anything specific to PHP.
This previous thread provides some useful information regarding writing secure PHP code:
What security issues should I look out for in PHP
If we take the "They used these vulnerabilities to inject PHP code into the site" part of the article literally, then the developers likely used user input with include/require statements or eval
The article isn't particularly clear, but my guess is that they just used SQL injection and, to try to avoid detection, they inserted a script that didn't actually change the behavior of the site normally unless the visitor came from Google using a relevant search term, and the author is calling the redirection in that situation "piggybacking".
So: escape and validate all user input.
First link really on the general subject should give you some overview.
Second link is PHP / SQL - specific and should lead you to enlightenment.
The BBC news article is talking about "persistent xss". Leave it to the news to talk about hacking without mentioning anything about vulnerabilities. But that could be that the bbc.co.uk dosen't know what an xss vulnerability is, because if they did they would patch their own damn site!.
There are many ways to achieve remote code execution against a PHP web application. No one should ever call this "PHP Injection", if they call it this then they don't know what they are talking about. A Study In Scarlet is an excellent paper that details many different methods that an attacker can use to obtain remote code execution against a PHP application. This paper is intended for malicious hackers, not developers.
XSS is by far the easiest and most common method to nefariously palace advertisements on somebody's site.
I'm a PHP/MySQL noob who knows nothing about online security.
Could you point me to some resources that will aid in my knowledge? (Beginner level, please!)
I'll suggest two things:
Make sure Register_globals is off.
Use prepared statements.
This question is well-answered and covers MySQL injection attacks (one of the more common concerns.
This question is also well documented and covers XSS (cross site scripting) attacks well.
Lastly, learn about PHP.INI and how to set it up and what is actually open/closed and on/off. A good host will, for example, never turn on register globals, but you should at least know what it is and why to check it. PHP Security has resources on that and many other PHP security concerns.
PHP might not be the best start. Especially if you're largely hand-rolling your own code. It doesn't exactly hold your hand with security issues. (fd: I wish PHP would go away for a variety of reasons.)
But some general rules:
Don't trust anything that comes from the outside. Always assume the user is some jerk trying to break your app. Most of them won't be, of course, but there will eventually be one who is. Just because you gave the browser a <select> containing a, b, and c doesn't mean you'll get one of those back. Javascript isn't a guarantee of anything. Referers can be easily faked. POST data can be easily faked. Textboxes can contain any character, not just the ones you expect.
Don't copy-paste others' code into production if you aren't sure how it works. You have no idea how much of an eye the author has for security. In my experience, PHP copypasta in particular seems to be less reliable but more frequently blindly reused.
Don't trust yourself to perform the same ritual in dozens of different places. Yes, mysql_real_escape_string() will fix SQL injection, but then you have to remember to use it everywhere. This creates a lot of places where you might make a mistake and forget your escaping ritual. Use prepared statements instead, and the problem vanishes entirely. Another example: Pylons (a Python framework) rigs its templates so any variable is HTML-escaped unless you explicitly ask otherwise. XSS is no longer a problem, and I never have to worry about manually escaping everything I print.
Chris Shiflett is the go-to guy on PHP programming and security:
http://phpsecurity.org/ for his book "Essential PHP Security"
http://shiflett.org/ for his website, blog, etc.
He is Speaking at PHP CodeWorks in Sept/Oct.
If you have some time, you could take a look at the slides used by Stefan Esser during his conference at the Dutch PHP Conference a few months ago, which title was "PHP Security Crash Course for beginners".
There are a couple of PDF :
Part I - Introduction
Part II - XSS
Part III -CSRF
Part IV - SQL Security
Part V - Session Management Security
Part VI + VII - PHP Code Inclusion and PHP Code Evaluation
Those could be helpful.
Then, don't hesitate to search a bit for non-PHP-specific informations : some security problems (like XSS, SQL Injections, CSRF, ...) are not specific to PHP : only the technical means to avoid them are specific ; so, you could find plenty of informations on sites like Wikipedia, or the OWASP website