Securing Your Site Like It’s 1999
24ways.org
Securing Your Site Like It’s 1999
1–10 of 33 posts
Re: Securing Your Site Like It’s 1999
#2When I interview developers, I generally ask some basic questions about security - "Explain to me what an XSS attack is?", or "How would you defend a web app against SQL injection?"
Basic stuff, which - to my mind - literally every person who develops anything which is on the web should know.
And a surprising number of people - even "senior" developers can't answer this stuff. It's really worrying.
Re: Securing Your Site Like It’s 1999
#3When I interview developers, I generally ask some basic questions about security - "Explain to me what an XSS attack is?", or "How would you defend a web app against SQL injection?" Basic stuff, which - to my mind - literally every person who develops anything which is on the web should know. And a surprising number of people - even "senior" developers can't answer this stuff. It's really worrying.
maybe its the fault of businesses of not training their staff in security and taking it seriously...until a breach happens.
Re: Securing Your Site Like It’s 1999
#4The article mentions creating a clear access control policy. I haven’t worked on access control at all, but I’ve witnessed colleagues at multiple companies implementing it, something which I’ve only seen being done by hand. This obviously leads to bugs and security issues. I always wondered whether there wasn’t already software built solely or partly for the purpose of access control.
I’ve recently been reading about LDAP. While I don’t have any experience using it, I wondered whether you could simply use LDAP to implement your access control. Someone on Stack Overflow asked the same question: https://stackoverflow.com/questions/3363267/ldap-for-applica.... The accepted answer mentions that LDAP can be used for high-level access information, but that the lower level should be handled by the application, as the LDAP scheme would otherwise become complicated. Fair enough.
My question is: What experience do others here have with implementing access control? Have you used LDAP? Is there another general tool built for this purpose which saves us the trouble of building our own system? Surely someone like IBM and Microsoft have built something for this. Are there any open source alternatives?
Re: Securing Your Site Like It’s 1999
#5The article mentions creating a clear access control policy. I haven’t worked on access control at all, but I’ve witnessed colleagues at multiple companies implementing it, something which I’ve only seen being done by hand. This obviously leads to bugs and security issues. I always wondered whether there wasn’t already software built solely or partly for the purpose of access control. I’ve recently been reading about…
Microsoft's architecture usually uses Kerberos Delegation, so access control is implemented in the backend. Say you've got an IIS web server, and SQL server; when the user logs into your application, they either delegate their tgt to the webserver or the web server gets a ticket on behalf of the user via Kerberos Protocol Transition (if they used a username and password in a form), the IIS server then authenticates to the backend, essentially impersonating the end user, so that the backend SQL server can look at it's own ACLs, rather than the web server having full access to the database and implementing its own ACLs. All this relies on having users in LDAP (specifically Active Directory). You could also go with what most people do, which is what is described in that article, in that you have groups as roles in LDAP, and simply lookup what groups a user belongs to, to determine access levels.
Re: Securing Your Site Like It’s 1999
#6The article mentions creating a clear access control policy. I haven’t worked on access control at all, but I’ve witnessed colleagues at multiple companies implementing it, something which I’ve only seen being done by hand. This obviously leads to bugs and security issues. I always wondered whether there wasn’t already software built solely or partly for the purpose of access control. I’ve recently been reading about…
There's Shibbeloth: https://www.shibboleth.net/
Not as easy as LDAP, it's designed for bigger places, like Universities
Re: Securing Your Site Like It’s 1999
#7The article mentions creating a clear access control policy. I haven’t worked on access control at all, but I’ve witnessed colleagues at multiple companies implementing it, something which I’ve only seen being done by hand. This obviously leads to bugs and security issues. I always wondered whether there wasn’t already software built solely or partly for the purpose of access control. I’ve recently been reading about…
We've used LDAP for authentication by binding as the user and checking if they belong to certain groups. Those groups are then used to give the user certain abilities.
https://github.com/debolk/bolklogin
User management was done through gosa / fusiondirectory.
Re: Securing Your Site Like It’s 1999
#8The article mentions creating a clear access control policy. I haven’t worked on access control at all, but I’ve witnessed colleagues at multiple companies implementing it, something which I’ve only seen being done by hand. This obviously leads to bugs and security issues. I always wondered whether there wasn’t already software built solely or partly for the purpose of access control. I’ve recently been reading about…
I've extensive use with LDAP over the last 20+ years or so.
It's great for various authenticating various Linux/UNIX system bits and applications - in the past I've supported everything from Tacacs and Radius, Apache with LDAP auth, storing SSH public keys (both hosts and user keys), password expiration policies and even sudo rules stored in LDAP.
There is a pretty steep learning curve though and there are many, many applications out there (particularly commercial ones) that claim to support LDAP but when you take a closer look their support is pretty broken and it can take a lot of effort to get everything working.
LDAP also has some legacy warts, and competing/incompatible bits - for example LDAP-TLS vs the deprecated LDAPS, RFC2307 vs RFC2307bis schemas etc. Working with LDIF can be an utter pain sometimes (esp. with trailing whitespace) and the management tools outside of Active Directory leave a lot to be desired.
It still beats the heck out of trying to synchronize tens/hundreds/thousands of user accounts with something like Puppet, which I've seen so many devops orgs do badly.
Re: Securing Your Site Like It’s 1999
#9When I interview developers, I generally ask some basic questions about security - "Explain to me what an XSS attack is?", or "How would you defend a web app against SQL injection?" Basic stuff, which - to my mind - literally every person who develops anything which is on the web should know. And a surprising number of people - even "senior" developers can't answer this stuff. It's really worrying.
“What is the OWASP top 10?”
I can forgive someone who can’t explain how XSS or CSRF works (I’m not sure I can explain it so clearly myself—kudos to the article’s author for the excellent explanation) if they know about the top 10 and have read it at least once.
Re: Securing Your Site Like It’s 1999
#10When I interview developers, I generally ask some basic questions about security - "Explain to me what an XSS attack is?", or "How would you defend a web app against SQL injection?" Basic stuff, which - to my mind - literally every person who develops anything which is on the web should know. And a surprising number of people - even "senior" developers can't answer this stuff. It's really worrying.
I've been developing web apps since .NET 3, and the only thing I understand (and can claim to guard against [1]) in the OWASP top 10 is SQL injection. I always try to explain to my clients that web security is a complex field and they should hire a pro for that area... which, given that Google itself seems to have problems with it, is quite difficult.
[1] - claim, because you never know when someone happily calls exec_sql with a string from a stored procedure (had it happen at two different companies).