Sécurité et contrôle de la cache!

Plusieurs attaques requièrent l’utilisation de la cache d’un fureteur. À sa plus simple expression, il est donc possible pour un malfaiteur d’accéder à ces données, si elles ne sont pas protégé correctement.

Pour adresser ce point de sécurité, il est donc critique de retirer toute forme de cache possible. Que celles-ci se trouvent dans votre fureteur ou par le fait même, dans votre serveur web et même vos autres outils de sécurité réseau.

Contrôler la cache dans sa solution avant tout

Depuis plusieurs années, je remarque dans les solutions observé l’utilisation de méta données dans les pages web, par exemple :

<meta http-equiv="cache-control" content="no-cache">

<meta http-equiv="expires" content="0">

<meta Http-Equiv="pragma" Content="no-cache">

À première vue ceci semble parfait, mais cette solution possède un grave manquement… Elle ne touche pas du tout vos équipements réseau!

Ceci veut donc dire que le fureteur pourra ultimement être rafraîchie, mais que des données pourront toujours se trouver dans vos gestionnaires de cache, balanceurs et autres équipement.

Aussi, il est fort possible que certaines de ces commandes ne fonctionne pas avec plusieurs fureteurs se trouvant dans le marché actuel.

Pour répondre à ces besoins, il faut donc descendre d’un niveau et adresser les fureteurs ainsi que les équipements.

Réduire la cache

Pour solutionner en profondeur, ma recommandation est simple; directement attaquer les entêtes HTTP.

L’utilisation d’entête garantie qu’au minimum, tous les équipements dans la chaîne répondant aux normes web devront suivre les clauses indiqué, par exemple celles-ci:

Cache-Control: no-cache, no-store, must-revalidate

Pragma: no-cache

Expires: 0

Mais comme nous adressons les entêtes elles-mêmes, il faut donc travailler au niveau du protocole. Il est certain que pour différents langages il existe différentes solutions, mais voici deux bons exemples pour vous. Ceci devrait vous permettent de facilement solutionner vos enjeux dans le code de votre choix. Mon but est simple, vous mettre la puce à l’oreille! Voici donc pour PHP et java.

header("Cache-Control: no-cache, no-store, must-revalidate");

header("Pragma: no-cache");

header("Expires: 0");

response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate");

response.setHeader("Pragma", "no-cache");

response.setHeader("Expires", "0");

Idéalement, si vous voulez aller plus loin et “doubler” la protection, il ne faut pas se gêner et introduire le contrôle directement dans votre serveur web comme ceci dans Apache (fichier .htaccess) :

<IfModule mod_headers.c>

    Header set Cache-Control "no-cache, no-store, must-revalidate"

    Header set Pragma "no-cache"

    Header set Expires 0

</IfModule>

Métadonnées vs entêtes HTTP

La puissance des entêtes est fort simple : celles-ci sont présentées dès la connexion http, avant l’apparition de la page HTML elle-même; et ce à travers chacun des équipements dans votre réseau et vos solutions.

Cette approche nous permet donc de limiter les dommages potentiels et surtout, ne pas se limiter au fureteur en question! Surtout si c’est celui d’un malfaiteur…

De plus, utiliser les entêtes éliminent les différences que chacun des fureteurs possèdent. Comme les utilisateurs utilisent des mobiles, des laptop et autres équipements pour se connecter, les entêtes sont indifférentes  et donc renforce le tout devant les fureteurs.

Suivant mon expérience, il ne faut donc jamais faire confiance <meta http-equiv> tags et toujours renforcer via notre code et directement au niveau du serveur web.

MacOS – TimeMachine est lent!

Time Machine est le service de sauvegarde automatisé de MacOS depuis des années. Avec cette maturité, comment est-il possible que celui-ci soit si lent?

Et bien j’ai une solution pour vous. Celle-ci est simple et n’affecte pas négativement votre Mac!

Pour vous donner une idée, je viens de compléter une pleine sauvegarde de mon Mac (environ 30 GB) en 5 minutes. En temps normal, ceci aurait pris 4 heures…

Cette commande permet donc de faire une sauvegarde de plusieurs gigaoctets (GB) en quelques minutes; plutôt qu’en quelques heures!

Sans trop entrer dans les détails, Time Machine est configuré pour rouler en arrière-plan sur votre Mac pour ne pas impacter votre travail. Sur ce, quand vous voulez accélérer les choses, une simple commande dans votre terminal sera en mesure d’accélérer les choses pour faire une sauvegarde rapide; très rapide.

Il s’agit de donner une priorité supérieur à Time Machine. Pour ramener les choses telles qu’elles étaient, il s’agit de simplement redémarrer votre Mac et le tour est joué.

Pour entrer la commande, démarrer votre terminal trouvé dans /Applications/Utilities/ ou dans le répertoire Utilités dans vos applications si vous avez un Mac en Français ou dans tout autre langues.

sudo sysctl debug.lowpri_throttle_enabled=0

Cette commande indique à votre Mac de prendre les processus d’arrière plan et leurs donner une priorité comme les autres. Vous ne devriez pas remarquer de différence dans vos autres apps, mais croyez-moi, Time Machine va rouler comme un champion.

Pour remettre le tout à la normale faire la commande suivante:

sudo sysctl debug.lowpri_throttle_enabled=1

Et voilà tout est revenu à la normale!

Sinon, il est toujours possible de redémarrer votre Mac et le tour est joué!

Apple APFS (Apple File System)

Following June 5th 2017 presentation, I thought updating my article and sharing it was great timing. File systems are key to systems operation, and few people have a clue about key details so here we go!

After running MacOS Sierra (High Sierra standard to come) for the past weeks and now year, I need to take some time and write about APFS, the new Apple File System.

APFS is not yet a full feature on Sierra but it the “new” filesystem format that Apple is planning to use on next operating systems; plans for next year [this year – 2017] for a potential user production environment in iOS and macOS…

But at the moment, APFS misses out on some key features in the world of storage, including that it’s block based and, it somewhat lacks full end-to-end integrity. But time will show us what is what, if HFS lasted 30+ years, I think we’re good for now with APFS!

Apple details the new APFS file system as such:

“Apple File System is a new, modern file system for iOS, macOS, tvOS, and watchOS. It is optimized for Flash/SSD storage and features strong encryption, copy-on-write metadata, space sharing, cloning for files and directories, snapshots, fast directory sizing, atomic safe-save primitives, and improved file system fundamentals.”

So currently, MacOS Sierra and previous versions of OSX use HFS+ and older system HFS file systems are more than 30 years ago… If by any chance you have no clue about what I’m talking about, take a little and read the following before going forward.

Here the main differences between APFS and HFS+ as detailed on Apple’s website:

Features Mac OS Extended (HFS+) Apple File System (APFS)
Number of allocation blocks 232 (4 billion) 263 (9 quintillion)
File IDs 32-bit 64-bit
Maximum file size 263 bytes 263 bytes
Time stamp granularity 1 second 1 nanosecond
Copy-on-write
Crash protected Journaled
File and directory clones
Snapshots
Space sharing
Full disk encryption
Sparse files
Fast directory sizing

With all this information this in mind, Sierra does blocks many powerful features of APFS; hey it’s still in beta… So here are the main limitations currently on Sierra beta release of APFS:

  • No APFS on a startup disk (slowly will come of age in the next release of MacOS High Sierra)
  • No APFS on Fusion Drives
  • No network sharing
  • No encryption with FileVault
  • All APFS volumes are case-sensitive
  • No APFS volume with Time Machine

Once APFS is in production, most if not all of these limitations will be removed and available. Of course, Apple may change things here and there, but the idea is to make APFS the standard in the next evolution of MacOS High Sierra.

This change is somewhat simple to understand, as APFS will greatly improve writing efficiency… new macs now use, SSD’s.

Some added value comes from the fact that SSD’s need to erase data before writing anything new on the disk.

It sounds a bit weird, but that’s how it works. So if Apple can find a way to streamline the writing and removing of data on SSD’s using advance techniques and caching, which would make a great difference… but wait…? Apple is doing that with the help of APFS!

To support these new fast drives, APFS will increase indexing file numbers (Inodes) by using and supporting 64 bit inodes. This is compared to HFS+ that uses 32 bit inodes. This means the old file system (32 bit) supports around 4 billion nodes, but with the ever-demanding data needs, this is getting a bit tight for bigger disk.

For example, APFS support 9 quintillion files on a single volume; ish, now there’s a big gap!

Also, other advance features such as real-time cloning, snapshots, space sharing, crash protection and single and multiple key encryption are all natively part of APFS. As this file system will find itself on tvOS, IOS, macOS and more devices (Apple Car anyone?) these features are necessary.

But remember, most mac users may not need these sizes and key features, but when you start going into the development, research or graphic environments, you need these; keeping in consideration that Petabyte environments are not that far away for users…

The change to APFS also enables the addition of file attributes within the same environment. You won’t need to separate the files and the file attributes like in HFS. When you’re in a disk with a lot of data, you can go from milliseconds to nanoseconds, and that, makes a big difference in the grand scheme of things. Suddenly, key features such as massive searches and so on are more responsive and thus, make the whole system faster and more responsive.

APFS also supports advance encryption methods outside of filevault (AES-XTS and AES-OBC) based on hardware and not only software. So again, performance gains right there.

So all in all, many other features are already or will be available for new MacOS releases, but as Apple put it on the developer site:

“HFS+ and its predecessor HFS are more than 30 years old. These file systems were developed in an era of floppy disks and spinning hard drives, when file sizes were calculated in kilobytes or megabytes.”

 

Article Notes

Q&A details publicly given by Apple

Why did Apple develop APFS?

Apple File System provides strong encryption, ultra-low latency and limited memory overhead. It is optimized for Flash/SSD storage and can be used on everything from an Apple Watch to a Mac Pro.

Can RAID be used with Apple File System?

Yes. Apple File System does not directly implement software RAID; however APFS-formatted volumes can be combined with an Apple RAID volume to support Striping (RAID 0), Mirroring (RAID 1), and Concatenation (JBOD). APFS-formatted volumes can also be used with direct-attached hardware RAID solutions.

Does Apple File System support directory hard links?

Directory hard links are not supported by Apple File System. All directory hard links are converted to symbolic links or aliases when you convert from HFS+ to APFS volume formats on macOS.

Does Apple File System support ditto blocks?

Ditto blocks are primarily used to protect against corrupted sectors in large storage arrays with unreliable hard disk drives. Apple File System takes advantage of modern hardware with strong checksums and error correction in firmware, and does not depend on ditto blocks.

Does Apple File System support redundant metadata?

With modern Flash/SSD storage, writing two blocks of data to different locations does not guarantee that the blocks will be written to separate locations. The Flash translation layer typically groups writes together into the same NAND block. Therefore it affords no extra protection to write a second copy at the same time the first copy is written.

What has Apple done to ensure the reliability of my data?

To protect data from hardware errors, all Flash/SSD and hard disk drives used in Apple products use Error Correcting Code (ECC). ECC checks for transmission errors, and when necessary, corrects on the fly. Apple File System uses a unique copy-on-write scheme to protect against data loss that can occur during a crash or loss of power. And to further ensure data integrity, Apple File System uses the Fletcher’s checksum algorithm for metadata operations.

Does Apple File System use journaling?

Apple File System uses copy-on-write to avoid in-place changes to file data, which ensures that file system updates are crash protected without the write-twice overhead of journaling.

Does Apple File System support data deduplication?

No. With Apple File System individual extents can be encrypted, making it impossible to examine and deduplicate files and their content. Apple File System uses clone files to minimize data storage and data duplication.

Does Apple File System support TRIM operations?

Yes. TRIM operations are issued asynchronously from when files are deleted or free space is reclaimed, which ensures that these operations are performed only after metadata changes are persisted to stable storage.

Is APFS open source?

An open source implementation is not available at this time. Apple plans to document and publish the APFS volume format specification when Apple File System is released for macOS in 2017.

Utiliser le format PDF (vecteur) pour les images dans Xcode

Voici comment utiliser le format PDF dans Xcode quand on veut utiliser une référence simple en format vecteur. Ça semble aléatoire, toutefois cette technique permet de créer une image unique pour tous les formats de iPhone, iPod et iPad, plutôt que devoir les créer individuellement… sauve beaucoup de temps!

La réponse est en anglais sur le forum StackOverflow – communauté #1 en programmation. Envoyez un commentaire si vous voulez plus de détails.

Grosso modo, il s’agit de créer l’image en format PDF puis de la référencer l’image dans les “assets” de Xcode.

http://stackoverflow.com/questions/31979160/new-tab-bar-icons-in-pdf-format-guidleines-to-create-custom/33749494#33749494

Image ou icône dans le navbar

Dans ayam, je voulais simplement faire l’ajout de l’icône de l’app dans la barre de navigation. Voici donc la solution – celle-ci est incluse directement dans le viewDidLoad du ViewController en question.

look_update

Pour changer l’image, simplement indiquer le nom désiré dans imageNamed:@”nom_image_ici”

self.navigationItem.titleView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:@"appsettings-small.pdf"]];

Nouvelles section sur deij.com – Solutions significatives Xcode & iOS

Avec l’avancement de notre app ayam – accessible sur le Apple App Store – il n’est que naturel de partager mes solutions les plus significatives quand je code dans Xcode.

Comme les solutions sont souvent complexes à trouver, je vais maintenant partager cells-ci avec vous. De plus, qu’avec chaque nouvelle versions de Xcode et iOS, il y a toujours des enjeux quand vient le temps de mettre à jour l’app, améliorer nos fonctions ou simplement, ajouter des éléments.

Pour accéder à ces articles spécifiques, j’ai inclus une puce additionnelle dans le menu – nommée Xcode / iOS. Ces articles seront généralement très courts et se concentrer précisément sur un enjeu et sa solution.

Perspective on Parse Local Datastore for iOS

This is in part an excerpt from the parse documentation. This small post is based on my solution architecture perspective on the Parse Local Datastore* for iOS.

Why use a local Datastore when using parse and iOS…

Usually, we use local Datastores to keep the information when our App is offline (no connection, airplane mode, etc.).

But other problematic scenarios may be solved using this approach, such as – performance issues.

From my experience and many reads on the Internet, developers simply integrate parse’s InBackground method to query’s and thus “free flow” the

App and virtually speed up the screen presentations. Not a bad idea.

But this approach may be fundamentally wrong from start and for a very simple reason… timing.

When you use the InBackground method without pinning, your App may present the next screen faster than the query, thus leaving your scene empty or simply presenting you with errors.

I’ve personally lived this with my partner in crime more than a few times, and this is not good, nor fun. Here’s an example from the parse.com website:

 PFQuery *query = [PFQuery queryWithClassName:@"GameScore"];
 [query whereKey:@"playerName" equalTo:@"Dan Stemkoski"];
 [query findObjectsInBackgroundWithBlock:^(NSArray *objects, NSError *error) …
 }];

Aware of this potential shortcoming, the need for a local Datastore is great news (in some cases caching with parse is great, but this subject will be for a later write up, as caching has key limits. I hope this will change in time to become more powerful.).

Finally, this is not a parse “how-to”, so if you’re not comfortable on the subject, I highly recommend going on parse.com and read up on the solution, it is very simple to understand. Here we go:

[PFObject pin] / [PFObject unpin]

Instead of just creating a “standard” PFQuery and “waiting” for results or going in background, we can now “pin” (save data) and “unpin” (remove data). Simply:

  • [PFObject pin] persists PFObjects to the Local Datastore.
  • [PFObject unpin] removes them.
  • Once pinned, we can access the data with a normal PFQuery.

The following is a simple example from parse.com documentation. Key references are in bold to easily view the information.

PFQuery *query = [PFQuery queryWithClassName:@"Feed"];
 // Pin PFQuery results
 NSArray *objects = [query findObjects]; // Online PFQuery results
 [PFObject pinAllObjectsInBackground:objects];
 ...
 // Query the Local Datastore
 [query fromLocalDatastore];
 [query whereKey:@"starred" equalTo:@YES];
 [[query findInBackground] continueWithBlock:^id(BFTask *task) {
 }]];

Does my data persist when users quit the App?

Yes. Parse’s documentation confirms the following:

“Pinned PFObjects will remain accessible while offline — through app exits and restarts — until they are unpinned. Subsequent saves, updates, or deletes will keep your Parse Local Datastore results up-to-date.”

Can I update the information?

Yes. Objects can be updated using the saveEventually method. As confirmed by parse, the following will update the Local Datastore and then remotely.

The following is a simple example from parse.com documentation. Key references are in bold to easily view the information.

 feedItem.starred = YES;
 // No network connectivity
 [feedItem saveEventually];
 ...
 PFQuery *query = [PFQuery queryWithClassName:@"Feed"];
 [query fromLocalDatastore];
 [query whereKey:@"starred" equalTo:@YES];
 [[query findInBackground] continueWithBlock:^id(BFTask *task) {
 // "feedItem" PFObject will be returned in the list of results
 }]

What to remember

The key thing to remember is that enterprise and solutions similar to Parse gives us developers great tools, but we have to make sure we use them intelligently.

Methods such as findObjectsInBackground can blindfold developers into thinking all is good – as long as the connection time and speed is good. When it’s not, that’s when other solutions need to be implemented.