Tag Info

Hot answers tagged

12

As the author of the Ruby AEAD library, I can assure you that OpenSSL does support GCM on 1.0.1c. ~ $ /usr/local/bin/openssl version OpenSSL 1.0.1c 10 May 2012 ~ $ /usr/local/bin/openssl enc -help 2>&1 | grep gcm -aes-128-gcm -aes-192-gcm -aes-256-gcm If it is unavailable on your platform (OpenSSL added GCM support in 1.0.1, I believe), I have ...


6

Splitting the APIs is really the best option, since the public site only needs to be read-only, there's no reason for the write APIs to live on it. That also would give you the ability to implement additional restrictions more easily, like restricting the IP addresses that can access the admin site. Failing that, using an API Key as Polynomial mentioned ...


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 ...


5

As announced on openwall, this bug was related to non-ASCII characters with the 8th bit set: What's worse, in some cases (but not in all) one, two, or three characters immediately preceding the 8-bit characters were ignored by the password hash computation. Thus, many passwords containing characters with the 8th bit set are significantly easier to ...


5

The code you refer to has been corrected. If you check out the source on Github vs the posted diff fix by Solar Designer, you can see that the sign-extension has been noted and corrected (lines 553 through 556). Keep in mind that even though prefix $2a$ is not recommended, neither is $2x$ which simply states that the buggy implementation is being used -- ...


5

Essentially you just need to run through the standard OWASP Top 10 and focus on getting the access control stuff right. As far as authentication goes, basic auth should be avoided for a number of reasons. It's ugly, insecure, and isn't universally supported. The standard model is to provide users with a randomly generated API key that is separate from their ...


4

This question is too broad to be answered. To be honest, it just feels that you're asking someone to do your job for you. Having that said, I'll try to answer you in the best way possible. First thing you need to do is to take care of the OWASP Top 10 List. Pay close attention to injection vulnerabilities and session management. After that, make sure the ...


4

Model Binding is quite a nice feature and may add a plus to the overall security if it is properly used. Here is how it works (the code and the features apply to ASP.NET MVC but may be the same in Ruby): Suppose you have a form in a web page: <form action="/SendData"> Email: <input type="text" name="email" id="email"><br> ...


4

You need both a salt and an IV when you do... two distinct actions, one needing a salt and the other an IV. That's your case here. The salt relates to turning a password into a secret key. That's what is used in your example code: PBKDF2 is a password-based key derivation function. As anything which uses passwords, PBKDF2 needs configurable slowness (that's ...


4

I'm a Python programmer myself, in my opinion there isn't any limitation to Ruby compared to Python when it comes to coding your pentesting tools. So if you are familiar with Ruby, go for Ruby. It can be handy to understand other programming/scripting languages to analyze an exploit. From this perspective I'd encourage you to try and port exploits from ...


3

There are several weird things in your setup: ECB mode does not use any IV. You should not specify an IV when using ECB mode. Or, rather, you should not use ECB, which is weak (generally speaking). AES processes binary input, produces binary output, and uses a binary key. There is no character string whatsoever in AES; thus, any notion of encoding like ...


3

You understand correctly. The code you found includes a common nomenclature error. i originally misread the code. Tom Leek is correct. The code isn't screwing up, but rather it's using the salt while hashing then later using an IV while encrypting. Many people conflate the terms 'salt' and 'initialization vector'. They serve the same purpose, but are ...


3

If I wanted to avoid such risks, would it be safer to clone the git repository of the source code for the gem, and build the gem myself? Probably not. More effort is likely to go into releasing (and potentially approving) a gem for inclusion onto rubygems than you will go to when cloning the source, especially for popular gems. Furthermore, there ...


3

The risks are the same as with other language-specific package management systems (npm for node.js, pypi for python, CRAN for R, CPAN for perl etc.) Yet, it is very often prudent to install this stuff without superuser's privileges, or at least have the chance to review what is being installed. To do the review one may use an utility like fpm to roll up an ...


2

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 ...


2

OpenSSL has support for GCM; see for instance this answer. Since GCM has nothing to do with SHA-384, I suppose that you are actually asking about support for AES-256/GCM in the context of a SSL/TLS session. This is supported only with TLS 1.2, so you need client and server to support that version.


2

You'd have to ask them, but most likely it's because the simplest and quickest way to demonstrate that the bug was somehow exploitable was the excessive CPU thing. Gets the point across without much work for the programmer.


1

I'm not sure about your application, but what you seem to be missing is that the user has some sort of control over the model (i.e: the ability to delete it). If your application allows users to be created without any intervention/approval, anyone could create a new user (and thus, have a valid current_user), and remove all objects by just iterating ...


1

They do provide security fixes relating to Ruby - for example the fairly recent Security Update 2013-002 includes some Ruby stuff, as did 2013-001. They don't seem to have patched CVE-2013-4073 yet, but to be fair that vulnerability is only a couple of weeks old. As you imply in your question, the non-careless developer will never try and run a production ...


1

As an update to Dinu's comments, the models in many PHP frameworks suffer from this same kind of thing. There's very few that offer "restricted properties" that cannot be set from the load. Most of them just assume you know what you're doing when you "load()" the values into them and assign the properties accordingly - again, sloppy coding practices. ...



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