Search Results

Search found 6 results on 1 pages for 'pinkgothic'.

Page 1/1 | 1 

• Kubuntu: apt-get install of php5-dev: libtool version mismatch?

  - by pinkgothic

  (Warning, clueless-newbism ahead.) Background info: I'm actually trying to install/upgrade xdebug. sudo pecl install xdebug yields: downloading xdebug-2.0.5.tgz ... Starting to download xdebug-2.0.5.tgz (289,234 bytes) ............................................................done: 289,234 bytes 67 source files, building running: phpize sh: phpize: not found ERROR: `phpize' failed A quick google tells me that phpize is a part of a package called php5-dev, so off I ran to install that. My problem is that using sudo apt-get install php5-dev fails with this output: sudo apt-get install php5-dev Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: php5-dev: Conflicts: libtool (>= 2.2) but 2.2.6a-4 is to be installed E: Broken packages 2.2.6a-4 is greater than 2.2, so I'm not sure why it's hanging itself up at that point. I'm guessing the fact that it's not entirely numeric is throwing apt-get off? I can probably install xdebug manually (though I've never done this before, so picture me with a deer clueless-newb in headlights look here, violently shaking my head and begging for a simpler solution) rather than via pecl / aptitude, but is there a way I can make aptitude install php5-dev despite the bogus 'broken package' claim? Is it even bogus, or am I misreading the error message? Alternatively: Could I install phpize in some other way (e.g. via pear or pecl)?

  Read the article

• Kubuntu: apt-get install of php5-dev: libtool version mismatch?

  - by pinkgothic

  (Warning, clueless-newbism ahead.) Background info: I'm actually trying to install/upgrade xdebug. sudo pecl install xdebug yields: downloading xdebug-2.0.5.tgz ... Starting to download xdebug-2.0.5.tgz (289,234 bytes) ............................................................done: 289,234 bytes 67 source files, building running: phpize sh: phpize: not found ERROR: `phpize' failed A quick google tells me that phpize is a part of a package called php5-dev, so off I ran to install that. My problem is that using sudo apt-get install php5-dev fails with this output: sudo apt-get install php5-dev Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: php5-dev: Conflicts: libtool (>= 2.2) but 2.2.6a-4 is to be installed E: Broken packages 2.2.6a-4 is greater than 2.2, so I'm not sure why it's hanging itself up at that point. I'm guessing the fact that it's not entirely numeric is throwing apt-get off? I can probably install xdebug manually (though I've never done this before, so picture me with a deer clueless-newb in headlights look here, violently shaking my head and begging for a simpler solution) rather than via pecl / aptitude, but is there a way I can make aptitude install php5-dev despite the bogus 'broken package' claim? Is it even bogus, or am I misreading the error message? Alternatively: Could I install phpize in some other way (e.g. via pear or pecl)?

  Read the article

• HTTP requests and Apache modules: Creative attack vectors

  - by pinkgothic

  Slightly unorthodox question here: I'm currently trying to break an Apache with a handful of custom modules. What spawned the testing is that Apache internally forwards requests that it considers too large (e.g. 1 MB trash) to modules hooked in appropriately, forcing them to deal with the garbage data - and lack of handling in the custom modules caused Apache in its entirety to go up in flames. Ouch, ouch, ouch. That particular issue was fortunately fixed, but the question's arisen whether or not there may be other similar vulnerabilities. Right now I have a tool at my disposal that lets me send a raw HTTP request to the server (or rather, raw data through an established TCP connection that could be interpreted as an HTTP request if it followed the form of one, e.g. "GET ...") and I'm trying to come up with other ideas. (TCP-level attacks like Slowloris and Nkiller2 are not my focus at the moment.) Does anyone have a few nice ideas how to confuse the server and/or its modules to the point of self-immolation? Broken UTF-8? (Though I doubt Apache cares about encoding - I imagine it just juggles raw bytes.) Stuff that is only barely too long, followed by a 0-byte, followed by junk? et cetera I don't consider myself a very good tester (I'm doing this by necessity and lack of manpower; I unfortunately don't even have a more than basic grasp of Apache internals that would help me along), which is why I'm hoping for an insightful response or two or three. Maybe some of you have done some similar testing for your own projects? (If stackoverflow is not the right place for this question, I apologise. Not sure where else to put it.)

  Read the article

• HTML Purifier: Removing an element conditionally based on its attributes

  - by pinkgothic

  As per the HTML Purifier smoketest, 'malformed' URIs are occasionally discarded to leave behind an attribute-less anchor tag, e.g. <a href="javascript:document.location='http://www.google.com/'">XSS</a> becomes <a>XSS</a> ...as well as occasionally being stripped down to the protocol, e.g. <a href="http://1113982867/">XSS</a> becomes <a href="http:/">XSS</a> While that's unproblematic, per se, it's a bit ugly. Instead of trying to strip these out with regular expressions, I was hoping to use HTML Purifier's own library capabilities / injectors / plug-ins / whathaveyou. Point of reference: Handling attributes Conditionally removing an attribute in HTMLPurifier is easy. Here the library offers the class HTMLPurifier_AttrTransform with the method confiscateAttr(). While I don't personally use the functionality of confiscateAttr(), I do use an HTMLPurifier_AttrTransform as per this thread to add target="_blank" to all anchors. // more configuration stuff up here $htmlDef = $htmlPurifierConfiguration->getHTMLDefinition(true); $anchor = $htmlDef->addBlankElement('a'); $anchor->attr_transform_post[] = new HTMLPurifier_AttrTransform_Target(); // purify down here HTMLPurifier_AttrTransform_Target is a very simple class, of course. class HTMLPurifier_AttrTransform_Target extends HTMLPurifier_AttrTransform { public function transform($attr, $config, $context) { // I could call $this->confiscateAttr() here to throw away an // undesired attribute $attr['target'] = '_blank'; return $attr; } } That part works like a charm, naturally. Handling elements Perhaps I'm not squinting hard enough at HTMLPurifier_TagTransform, or am looking in the wrong place(s), or generally amn't understanding it, but I can't seem to figure out a way to conditionally remove elements. Say, something to the effect of: // more configuration stuff up here $htmlDef = $htmlPurifierConfiguration->getHTMLDefinition(true); $anchor = $htmlDef->addElementHandler('a'); $anchor->elem_transform_post[] = new HTMLPurifier_ElementTransform_Cull(); // add target as per 'point of reference' here // purify down here With the Cull class extending something that has a confiscateElement() ability, or comparable, wherein I could check for a missing href attribute or a href attribute with the content http:/. HTMLPurifier_Filter I understand I could create a filter, but the examples (Youtube.php and ExtractStyleBlocks.php) suggest I'd be using regular expressions in that, which I'd really rather avoid, if it is at all possible. I'm hoping for an onboard or quasi-onboard solution that makes use of HTML Purifier's excellent parsing capabilities. Returning null in a child-class of HTMLPurifier_AttrTransform unfortunately doesn't cut it. Anyone have any smart ideas, or am I stuck with regexes? :)

  Read the article

• IE and Content-disposition inline vs. extension-token

  - by pinkgothic

  Preamble So IE does Mime-Type sniffing. That part's old news. Suggestions of how to combat it tend to be along the lines of 'supply a content-type IE trusts' (i.e. anything that isn't text/plain or application/octet-stream) or 'add extraneous data at the start of the file that is definitely of the type you're serving'. Now, I'm working on an application that has to allow message attachments (like in e-mails), and we want to close up XSS vectors. IE's mime sniffing is one of those vectors - a text/plain file with html content will trigger as html. Recoding isn't an option at this point, changing the attachments the user has provided can only happen if there is absolutely no doubt about the maliciousness of the file - and someone might want to send HTML as text. Now, Microsoft's MSDN article implies the situation might be easier to fix than advertised: If Internet Explorer knows the Content-Type specified and there is no Content-Disposition data, Internet Explorer performs a "MIME sniff," [...] Great! Except I don't have IE nor current means to reliably install it (I realise this is a fairly sad state for a webdeveloper to be in, I hope to fix this soon) and this is grey theory that I can't quite seem to get confirmed one way or the other. Local sources say that line is hogwash - IE will mime sniff anything that is Content-Disposition: inline / <default> and not specific enough for its tastes in -Type. But what about x-* ('extension-token' in the RFC)? Trying to google for how browsers handle Content-Disposition: <extension-token> hasn't yielded anything (though I may just be doing it wrong, my understanding of Google is seriously slipping lately). I found one question that looked promising, but turned out to be a misunderstanding on side of the thread author, meaning that the train of thought was never actually addressed there. Question(s) Does IE really Mime sniff if you expressly pass Content-Disposition: inline? If so: Does anyone here know how browsers handle Content-Disposition: <extension-token>? If they do this in a way that is for my purposes benign, by presuming it to be synonymous with the default (effectively 'inline', though I hear it's not defined anywhere?), is it specific enough for IE not to Mime sniff? Or am I actually shooting myself in the foot by thinking of pursuing this avenue?

  Read the article

• PHPUnit and autoloaders: Determining whether code is running in test-scope?

  - by pinkgothic

  Premise I know that writing code to act differently when a test is run is hilariously bad practise, but I may've actually come across a scenario in which it may be necessary. Specifically, I'm trying to test a very specific wrapper for HTML Purifier in the Zend framework - a View Helper, to be exact. The HTML Purifier autoloader is necessary because it uses a different logic to the autoloaders we otherwise have. Problem require()-ing the autoloader at the top of my View Helper class, gives me the following in test-scope: HTML Purifier autoloader registrar is not compatible with non-static object methods due to PHP Bug #44144; Please do not use HTMLPurifier.autoload.php (or any file that includes this file); instead, place the code: spl_autoload_register(array('HTMLPurifier_Bootstrap', 'autoload')) after your own autoloaders. Replacing the require() with spl_autoload_register(array('HTMLPurifier_Bootstrap', 'autoload')) as advertised means the test runs fine, but the View Helper dies a terrible death claiming: Zend_Log[3707]: ErrorController caught LogicException "Passed array does not specify an existing static method (class 'HTMLPurifier_Bootstrap' not found)" (Our test folder structure is slightly different to our Zend folder structure by necessity.) Question(s) After tinkering with it, I'm thinking I'll need to pick an autoloader-loading depending on whether things are in the test scope or not. Do I have another option to include HTMLPurifier's autoloading routine in both cases that I'm not seeing due to tunnel vision? If not, do I have to find a means to differentiate between test-environment and production-environment this with my own code (e.g. APPLICATION_ENV) - or does PHPUnit support this godawful hackery of mine natively by setting a constant that I could check whether its been defined(), or similar shenanigans? (My Google-fu here is weak! I'm probably just doing it wrong.)

  Read the article

1