view release on metacpan or  search on metacpan

lib/Catalyst/Plugin/Session/Tutorial.pod  view on Meta::CPAN

        <thead>
            <tr>
                <th>Item</th>
                <th>Quantity</th>
                <th>Price</th>
                <th>remove</th>
            </tr>
        </thead>

        <tbody>
        [%# the table body lists all the items in the cart %]
        [% FOREACH item_id = cart.items.keys %]

            [%# each item has its own row in the table %]

            [% item = cart.items.$item_id %]
            [% quantity = cart.quantity.$item_id %]

            <tr>
                <td>
                    [%# item.name is an attribute in the item
                      # object, as loaded from the store %]
                    [% item.name %]
                </td>

                <td>
                    [%# supposedly this is part of a form where you
                      # can update the quantity %]
                    <input type="text" name="[% item_id %]_quantity"
                        value="[% quantity %]" />
                </td>

                <td> $ [% item.price * quantity %] </td>

                <td>
                    <a href="[% c.uri_for('/cart/remove') %]/[% item_id %]">
                        <img src="/static/trash_can.png" />
                    </a>
                </td>
        [% END %]
        <tbody>

        <tfoot>
            <tr>
                <td colspan="2"> Total: </td>
                <td>
                    [%# calculate sum in this cell - too
                      # much headache for a tutorial ;-) %]
                </td>
                <td>
                    <a href="[% c.uri_for('/cart/empty') %]">Empty cart</a>
                </td>
            </tr>
        </tfoot>

    </table>

As you can see the way that items are added into C<< $c->session->{cart} >> is
pretty simple. Since C<< $c->session >> is restored as necessary, and contains
data from previous requests by the same client, the cart can be updated as the
user navigates the site pretty transparently.

=head1 SECURITY ISSUES

These issues all relate to how session data is managed, as described above.
These are not issues you should be concerned about in your application code,
but are here for their educational value.

=head2 (Not) Trusting the Client

In order to avoid the overhead of server-side data storage, the session data can
be included in the cookie itself.

There are two problems with this:

=over 4

=item 1

The user can change the data.

=item 2

Cookies have a 4 kilobyte size limit.

The size limit is of no concern in this section, but data changing is. In the
database scheme the data can be trusted, since the user can neither read nor
write it. However, if the data is delegated to the user, then special measures
have to be added for ensuring data integrity, and perhaps secrecy too.

This can be implemented by encrypting and signing the cookie data, but this is
a big headache.

=back

=head2 Session Hijacking

What happens when client B says "I'm client A"?  Well, basically, the server
buys it. There's no real way around it.

The solution is to make "I'm client A" a difficult thing to say. This is why
session IDs are randomized. If they are properly randomized, session IDs are so
hard to guess that they must be stolen instead.

This is called session hijacking. There are several ways one might hijack
another user's session.

=head3 Cross Site Scripting

One is by using cross site scripting attacks to steal the cookie data. In
community sites, where users can cause the server to display arbitrary HTML,
they can use this to put JavaScript code on the server.

If the server does not enforce a strict subset of tags that may be used, the
malicious user could use this code to steal the cookies (there is a JavaScript
API that lets cookies be accessed, but this code has to be run on the same
website that the cookie came from).

=head3 Social Engineering

By tricking a user into revealing a URI with session data embedded in it (when