Thought Delimited

A cross-site request forgery (CSRF) occurs when a hacker takes advantage of the fact that users don't always log out of the websites and web applications they visit. The hacker creates a URL or a form that passes valid data to a valid destination on the target website and hopes that a user who is still authenticated to that website clicks that malicious URL or form. If such a user falls into the trap, the target website will process the request just as if the user had executed the action within the target website under normal circumstances.

One common method for preventing CSRF attacks is to generate a unique value every time a user visits a form on the website and store that value both within the user's session and within the form itself as a hidden field. When the form is submitted, the value in the form is checked against the value stored within the user's session, and if they don't match the form submission isn't processed. The next time the user encounters a form (even if it's the same form), a new unique value is generated. Without a way of knowing what that unique value is at any given time, the hacker cannot build a form or construct a URL that simulates a legitimate request, and the attack fails.

Rather than have to remember to create these unique values and include them within every form (or every URL that executed some sort of data operation), and then check the validity of the submitted value on each processing page, I wanted to see if there was a way I could build CSRF security into the structure of my Model-Glue applications.

Read more...

So yesterday, during the first half of the morning keynote at the Google I/O conference, Google made several announcements about the latest version of the Android OS:  version 2.2, codenamed "Froyo."  Here are several links to pages that go through the announcements:

http://android-developers.blogspot.com/2010/05/android-22-and-developers-goodies.html

http://www.dzone.com/links/r/android_22_and_beyond.html

http://www.blog.droidweb.com/2010/05/android-2-2-annoucned-at-google-io-what-it-means-for-you/

A couple of additional notes:

• One of the announcements was that you could initiate actions on your phone via the "the cloud" (the Internet). In the demo, the presenter's assistant was able to get driving directions on his laptop using the Chrome browser and then send those directions to his Android phone by clicking on a certain link. The presenter said that browser initiated an "intent" on the Android device.

  In Android development, an Intent is a messaging object directed at a component (an Activity, a Service, or a Broadcast Receiver) within an Android application and delivers data to the component. Normally, an Intent can either be explicitly addressed to a specific component by name, or it can be implicitly targeted towards any component whose intent filters make them capable of receiving the intent. I'm curious to see how Google will implement this feature to make sure this capability isn't used maliciously.

• Another announcement was that Android 2.2 would allow developers and users to install applications on the SD card in the Android phone rather than in the phone's internal memory, something that many Android users have wanted for a long time.  The Android Developer site already has a documentation page up regarding this feature, which I glanced over.

  When they write an application using the API for Android 2.2 (apps written to an earlier API will NOT be movable to the SD card using the features in Android 2.2), developers can specify one of the following install locations within their application's manifest file:

  • "preferExternal": the app will initially be installed to the SD card automatically unless the SD card is full. The user will have the option to move it to internal storage if they like.

  • "auto": Android will determine the best location for the initial installation for the app, but again the user has the option of moving it.

  • "internalOnly": the app can only be installed in the internal memory of the device.

  The drawback to running an application from the SD card is that all application processes currently active on the SD card are killed whenever the user connects their Android device to their computer and chooses to mount the SD card as an external USB drive. Applications that use certain features can break when this situation occurs, and therefore such applications may have the "internalOnly" install setting in place to prevent problems.

  The documentation also points out that applications installed to the SD card will still store any private user data and databases for the application in the internal memory. So the need for a way to back up the application data was still needed even with the SD installation option, hence the announced feature in 2.2 that application data could be backed up to the cloud.

My last few Android development posts have been kind of long (took long to write anyway), so here's a short one...

Read more...

So overnight an update to ColdFusion Builder was released. According to the update instructions, if you're running ColdFusion Builder as a plug-in to Eclipse (like I am), you need to start/restart Eclipse clean, which can be done by typing "eclipse -clean" at the command prompt within your Eclipse folder.

The problem I ran into was I couldn't do that on my MacBook Pro. I opend up a Terminal window, navigated to my Eclipse folder, tried the command, and was told "command not found." 

I had an eclipse exec file in the directory along with the normal Eclipse.app application bundle file, so I'm not sure why it didn't work. I probably either did something wrong or perhaps there's something funky about my Eclipse install.

But fortunately I found another way to launch Eclipse with the clean option in an old set of Eclipse (3.3) documentation.  Here's what I did (after installing the ColdFusion Builder update):

• I opened a Finder window and navigated to my Eclipse directory.
• I right-clicked on the Eclipse.app application bundle icon, and selected "Show Package Contents" from the context menu.
• In the new Finder window that popped up, I went into Contents/MacOS, right-clicked on the eclipse.ini file, and chose to open it in TextEdit.
• I added "-clean" to the top of the eclipse.ini file, saved the file, then closed it.
• I then restarted Eclipse.
• Once Eclipse was up and running, I re-opened the eclipse.ini file, removed the "-clean" line, and saved it again.

In my last post, I talked briefly about how the R.java file, a resource file located in the "gen" folder of your Android application project that is automatically generated and updated by Eclipse and serves as a resource map. My example code demonstrated how you could reference layout.xml files via the R.java file and how Eclipse would register the id of the UI objects within the R.java file as well.

I also mentioned that the layout XML files for your Android app are located in a "layout" folder within the "res" ("resources") folder.  There are other folders under the "res" folder as well, and the content within those folders is also registered with the R file, allowing you to access those resources within your Android code.

Read more...