Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re^7: Best practices for closing database connections?

by marto (Cardinal)
on Mar 17, 2022 at 15:45 UTC ( [id://11142189]=note: print w/replies, xml ) Need Help??


in reply to Re^6: Best practices for closing database connections?
in thread Best practices for closing database connections?

CSRF can and is exploited to execute functions on logged in systems, say for example a URL in an email linking to an exploitable system. The end user doesn't know, they just click and if they're already logged in the command will run as though they'd been malicious. The point I specifically addressed falls into this category. Not using simple existing methods of coping with this, either CSRF or SQL injection when they exist, I'd safely describe that as not best practice. When it comes to security it's best not to make assumptions.

The reason I asked about performance was that my experience is that people who ask such questions tend not to have profiled their application or tuned their database. Your mileage may vary, however Advanced DBI is worth reading, it contains a lot which is well worth working through, including connection caching options, I notice someone had mentioned Mojolicious persistence elsewhere in the thread, it's not specific to this framework.

Perhaps of interest:

Replies are listed 'Best First'.
Re^8: Best practices for closing database connections?
by Polyglot (Chaplain) on Mar 17, 2022 at 16:38 UTC

    There's no way to be already logged in on my system. I don't use cookies. If you so much as reload the page, you'll have to login again the way I have it. A link to the URL will force a login. The only way that an exploit could be easily done is to create an imitation on a different website/URL that would emulate my page and entice the user to surrender his or her login credentials (username/password)--and that could then be used to login on the real site by a malicious user. I don't know any way to prevent an attack of this sort, however, even with the best of security practices in place; virtually any site could be spoofed. But the site is hardly much of a target, and would not be worth a hacker's time, as I see it.

    Further to this, the site is not using the GET protocol. The URL is always basic, without additional hackable tokens. It's all based on POST.

    Though the server itself has been subjected to multiple DoS attacks and hacking attempts over this period, perhaps it is enough that for all the supposed weaknesses in the system, this application has been online for over eight years without a single break-in/hack-in. Nor do I expect any significant trouble in the years to come, barring the site achieves a much greater level of notoriety than it now has (unlikely).

    But we digress, and I fear I am still nearly as ignorant about database connections as when I first posted.

    Blessings,

    ~Polyglot~

      "But we digress, and I fear I am still nearly as ignorant about database connections as when I first posted."

      I doubt sufficient time has passed to allow you to read the slides I linked to (also linked from the DBI documentation) and think about the options afforded to you.

        I read the Wikipedia page you linked, and the cartoon's been saved on my hard drive for some time now. I haven't seen any slides.

        Blessings,

        ~Polyglot~

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11142189]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others meditating upon the Monastery: (7)
As of 2024-03-28 10:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found