Tag Info

Hot answers tagged

13

Ignore them. They look like automated scripts looking for common vulnerabilities in sites on the Internet. You say your site is built using RoR so the server most likely doesn't contain software like phpmyadmin. You won't be affected.


8

Rails 3 has some pretty good protections switched on by default which will catch a lot of common security issues. Specifically output encoding will help mitigate XSS attacks, the CSRF tokens are enabled by default on all forms which should help here, and as long as you use it correctly ActiveRecord or other ORMs can help with mitigating SQL injection. On ...


7

You asked: Am I exposing potential vulnerabilities by exposing the same session cookie to all my users' subdomains? Answer: It depends, but generally speaking, yes, you could be exposing yourself to some attacks. It depends upon what kind of content you allow on the subdomains (e.g., elmer.acme.com). There are two cases: If you allow Elmer to put ...


7

The OWASP XSS Cheat Sheet is a great resource to understand all the ways XSS can happen: RULE #0 - Never Insert Untrusted Data Except in Allowed Locations RULE #1 - HTML Escape Before Inserting Untrusted Data into HTML Element Content RULE #2 - Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes RULE #3 - JavaScript Escape Before ...


6

Linode uses Xen, which means that you not only have an app; you have a whole operating system, complete with kernel and base libraries. The attack comes from your system, so it is completely in your jurisdiction. The attacker entered your system in some way, but once there, if he is at least half competent, he used a rootkit to transform his break-in into a ...


6

Yes. You want Brakeman, a tool that scans your RoR code for security vulnerabilities I recommend reading the OWASP Ruby on Rails Security Guide. You could also try any web pen-testing tool; they are not language-specific. There are many of them. They only find low-hanging fruit, not all security problems, but it can't hurt to use them just in case they ...


3

It doesn't sound like you were hacked to me, it sounds more likely that Slicehost had some sort of issue temporarily. The SSH message you got means that the key that was sent by the server was different from the one in your cache. Here are possible reasons that come to mind: - Another server may have been temporarily assigned the IP address, and then the ...


2

From the Ruby on Rails security Guide as long as you're using the reset_session command during the authentication process, you should be mitigating against session fixation attacks. In general with a rails app. if you're only creating the session when the user logs in and you're issuing a new Session ID at that point, you shouldn't have too many problems ...


2

I don't know how Slicehost works, but before considering the worst, I would try to contact them in order to have more information. As you are saying, you had a 20min down server, and when you tried to connect via SSH during this down time, your SSH key has changed. It can be an attack, but it's also possible that when a server is down, slicehost still ...


2

Disclaimer: I'm one of the developers at Tinfoil Security. We have a free and quick check at https://www.tinfoilsecurity.com/railscheck. Tinfoil's check was based off of Metasploit's original probe. I'm curious as to why we came up as vulnerable when Metasploit did not -- feel free to email support@tinfoilsecurity.com or visit us at ...


2

Sorry for a short response, but I'm sure others will fill in eventually. RPORT most likely means the port that the webserver is running on. I've not used metasploit for this yet, unless Tinfoil Security uses the same concept, see: https://www.tinfoilsecurity.com/railscheck -k0nsl


2

You need to study the traffic coming from your server. It will reveal if your server is connecting to SSH services on other networks. If you find no such evidence from the traffic generated from your server offer this proof to linode and have them either refute it or accept it. If you find evidence you need to go through network traffic, logs, running ...


1

Don't trust the URL... since POSTed data may hide what is really going on. The URL should be treated as a client-side value and should not be trusted anyway. Anyone can easily alter the URL and could easily create a POST to any UserID. Anyone who can guess the route variable names in ASP.NET MVC, can put unexpected data into a controller This can ...


1

You can prove it, if you can find a compromised system of any way, shape or form on your server. You have a part of the proof. Having a single line of a log file is not proof. So, this is really hard to "proof". IT Security has a lot to do with the WOT (Web of Trust) You need to let them "trust" you on some way. The easiest way do to this is to hand over the ...


1

I have not looked into your code, but the things I would do are: checking the eligibility of the user to do anything on your website before making that user makes an action. (If somebody posting something without even registering in the site - it is no good). to prevent from the new signup the common practice is to confirm yourself using a mail account or ...


1

I think this will help you to the question to your answer.



Only top voted, non community-wiki answers of a minimum length are eligible